План лекции

Singleton Один экземпляр объекта Паттерн Singleton Чем плоха статическая переменная? Динамическое создание (ленивая инициализация) Singleton на шаблонах Model-View-Controller Большую программу нужно разбивать на части Зависимость одних частей программы от других MVC --- как способ разбить программу на части MVC пример 1. Граф. приложение MVC пример 2. Веб-приложение Структура взаимодействия Пример. Шахматная программа. Шаблоны проектирования Книга Design Patterns. "Гибкий" код Плюсы паттернов Минусы паттернов Выводы

Singleton

Один экземпляр объекта

Бывает такая ситуация, когда нужно, чтобы можно было иметь только один экземпляр объекта. Примеры:

• Ведение логов - нужен объект, который отвечает за запись логов, например, в файл. Необходим только один экземпляр, так как нужно писать лог, используя один и тот же файл
• Хранение настроек - объект с настройками нужен только один, так как для всей программы настройки одни и те же
• Класс Application - класс "приложение" также нужен только один в программе

Паттерн Singleton

Паттерн Singleton ("Одиночка") решает эту проблему.

class Logger {
    public:
	static Logger* instance() {
	    return myInstance;
	}
    private:
	static Logger* myInstance;
    private:
	Logger();
    public:
	bool openLogFile(...);
	bool writeLogFile(...);
	bool closeLogFile(...);
    private:
	Logger& operator=(Logger const&);
	Logger(Logger const&);
};

Для того чтобы хранить только один объект в памяти, создается статическое поле объекта Logger -- myInstance, доступ к которому можно получить через публичный метод instance()

Инициализация статической переменной (код должен находиться в .cpp файле, где определяются методы класса Logger):

Logger* Logger::myInstance = new Logger(); 

Использование в программе:

int main() {
    Logger* loggerPtr = Logger::instance();
    loggerPtr->openLogFile();
}

Чем плоха статическая переменная?

• Создается всегда, даже если не нужна (излишнее потребление ресурсов).
• Создается раньше времени (например, до инициализации графической библиотеки)

Динамическое создание

� ешение проблемы со статической переменной:

Logger* Logger::myInstance = 0;
Logger& Logger::instance() {
    if (myInstance == 0) {
	myInstance = new Logger();
    }
    return *myInstance;
}

Здесь используется "ленивая инициализация" - объект создается в памяти при первом запросе к нему.

Кстати, здесь сделано еще одно изменение: возвращается не указатель, а ссылка. Это нужно для того, чтобы явно показать, что класс Logger создан в памяти (а не вернулся нулевой указатель)

Singleton на шаблонах

Допустим, у нас есть класс Logger:

class Logger {
    public:
	Logger();
    public:
	bool openLogFile(...);
	bool writeLogFile(...);
	bool closeLogFile(...);
};

Можно сделать класс Singleton на шаблонах, с помощью которого можно было классу Logger добавить возможности Singleton.

Шаблон класса Singleton:

template <class T>
class Singleton {
    public:
	static T& instance() {
		if (myInstance == 0) {
			myInstance = new T;
		}
		return *myInstance;
	}
    private:
	static T* myInstance;
    protected:
	Singleton() { }
    private:
	Singleton& operator=(const Singleton&) { return *this; }
	Singleton(const Singleton&) { }	
};

template <class T>
T* Singleton::myInstance = 0;

И, чтобы добавить классу Logger возможности Singleton, нужно унаследовать Logger от Singleton с параметром 'Logger':

class Logger : public Singleton<Logger> {
	private:
		Logger() { }
	public:
		bool openLogFile();
		bool writeLogFile();
		bool closeLogFile();

	friend class Singleton<Logger>;
};

Комментарии:

• Конструктор Logger() изменяет свой доступ с публичного на приватный, так как надо запретить создание таких объектов
• Singleton<Logger> объявляется friend, для того чтобы метод instance() мог вызвать конструктор класса Logger (new T)
• Конструктор Singleton() в шаблонном классе объявляется protected, для того чтобы нельзя было создать просто класс Singleton, и в то же время он должен быть доступен для вызова (неявного) из конструктора Logger()

Использование такого класса Logger в программе:

int main() {
    Logger& logger = Logger::instance();
    logger.openLogFile();
}

Model-View-Controller

Большую программу нужно разбивать на части.

Большая программа, разбитая на несколько частей, имеет много преимуществ, например:

• Маленькую часть программы проще писать, так как можно сконцентрироваться на конкретных задачах, которые эта часть решает
• Часть программы может быть полностью или частично изменена, кроме методов работы с ней, объявленных public, при этом не нужно изменять другие части
• Часть программы удобнее тестировать, чем всю программу вместе
• Если программа пишется несколькими людьми, каждый может работать только над своей частью, даже не зная, как устроены другие

Зависимость одних частей программы от других.

2 класса независимы друг от друга тогда, когда у них нет ссылок друг на друга:

Классы 1 и 2 имеют ссылку на класс 3. Класс 3 не имеет ссылок ни на кого, следовательно он независим от других классов. Т.е. при изменении классов 1 или 2, менять класс 3 не придется.

Независимость дает следующие преимущества:

• Внесение изменений в проект.

Легче вносить изменения в программу: классы 1 и 2 могут быть полностью изменены, или даже убраны, при этом в класс 3 изменения не вносятся. Правда, если класс 3 будет меняться, то придется вносить изменения во все зависимые от него классы.

• Повторное использование кода в других проектах.

Класс 3, так как он независим от других, можно использовать в других проектах.

Если бы класс 3 имел ссылки на класс 1 или 2, или на оба сразу, то класс 3 перестал бы быть независимым. Такая организация классов называется сильно связанной. При этом мы лишились бы всех описанных до этого преимуществ, поэтому, сильная связанность -- плохо. Программа должна представлять собой ациклический граф.

Паттерн MVC .

Паттерн MVC (сокращение от "Model-View-Controller") предлагает так разделять программу:

• Model (Модель) -- Внутреннее представление данных

Модель реализует внутреннее представление данных и обеспечивает к ним доступ.

• View (Представление) -- Отображение модели<

Представление обеспечивает вывод данных на экран, в форме, понятной пользователю.

• Controller (Контроллер) -- Взаимодействие

Контроллер отвечает за взаимодействие между Моделью и Представлением.

MVC пример 1. Графическое приложение.

Как правило, в графических приложениях Представление и Контроллер объединены вместе, так как за вывод на экран (Представление) фактически отвечает графическая подсистема не программы, а среды, в которой она запущена.

MVC пример 2. Веб-приложение.

Сетевые приложения реализуют Представление и Контроллер отдельно, так как это связано с особенностью устройства сети. Контроллер и Модель находятся на стороне сервера, а Представление - на стороне клиента. Представление не обращается к модели напрямую, все действия проходят через контроллер.

Например, сайт на экране бразуера -- Представление. Мы нажимаем на какой-либо ссылку на сайте, и браузер посылает на сервер запрос "загрузить эту ссылку". На стороне сервера Контроллер обрабатывает этот запрос, делает какие-то свои запросы к модели, чтобы получить необходимые данные, формирует ответ в виде HTML, и отправляет его обратно. Получив HTML страницу, наш браузер ее рисует

Структура взаимодействия

Кто и кому говорит "обновись" в паттерне MVC?

Модель не имеет ссылок на другие классы, Представление имеет ссылку на модель, а Контроллер имеет ссылку на оба этих класса. Поэтому, на контроллер ложится обязанность обновлять Представление, после того, как он произвел какие-то изменения модели

Но, Модель сама может изменяться независимо от Контроллера. Пример - модель "Часы", которая изменяется каждую секунду. В этом случае либо Контроллер должен периодически опрашивать ее, не изменилась ли она, либо модель должна иметь ссылку на Представление, и сообщать ему, что Модель обновилась. Но это создает циклическую зависимость Модели и Представления.

Пример. Шахматная программа.

С помощью паттерна MVC можно поделить программу "Шахматы" таким образом:

Модель - хранит доску (массив размером 8x8), и позволяет взаимодействовать с доской: посмотреть указанную клетку, сделать ход, посмотреть возможные ходы, проверить, если ли на доске шах:

class Board {
	public:
	    int getBoardCell(int x, int y);
	    makeMove(int x, int y, int x2, int y2);
	    getMoves();
	    bool isCheck();
	private:
	    int b[8][8];
};

Она хранит ссылку на Модель, так как в процессе своей работы оно запрашивает данные у Модели (например, для отрисовки доски, просматривает всю доску с помощью метода Модели getBoardCell():

В этом приложении Представление и Контроллер объединены вместе. Поэтому Представление также должно реагировать на действия пользователя, например, когда он ходит, он щелкает мышкой по доске, чтобы указать фигуру и куда он хочет сходить, поэтому оно имеет метод onMousePressed()

class View {
	public:
	    update();
	    onMousePressed(int x, int y);
	private:
	    Board *b;
};

Шаблоны проектирования

Книга Design Patterns. "Гибкий" код

Об этих и других шаблонах проектирования можно прочитать в книге "Приемы объектно-ориентированного программирования: паттерны проектирования" (авторы: Э. Гамма, � . Хелм, � . Джонсон, Дж. Влиссидес (название на английском: "Design Patterns. Elements of Reusable Object-Oriented Software")

Паттерны придумывались для того, чтобы писать "гибкий" код - такой, который легко изменять и дорабатывать.

Плюсы паттернов

• Паттерны - типовые проектные решения.

Паттерны представляют собой типовые проектные решения, применимые к очень многим проблемам, возникающим при проектировании.

Минусы паттернов

• Бездумное применение

Возможность изменять и расширять код требуется не во всех частях программы. Бездумное применение -- излишнее усложнение программы.

Выводы