Презентация на тему Паттерны проектирования (design patterns)

задач проектирования
Обобщенное описание решения задачи, которое можно использовать в

различных ситуациях
ОО паттерны проектирования часто показывают отношения и взаимодействия между классами и объектами
Алгоритмы не являются паттернами, т.к. решают задачу вычисления, а не программирования

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

позволяет, отыскав удачное решение, пользоваться им снова и снова
Шаблоны проектирования не зависят от языка программирования, в отличие от идиом

(Abstract Factory)
Строитель (Builder)
Фабричный метод (Factory method)
Прототип (Prototype)
Одиночка (Singleton)

взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов

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

создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов

Factory, который представляет собой интерфейс для создания абстрактных объектов-продуктов
На

основе данного класса создается один или несколько классов конкретных фабрик, создающих конкретные объекты-продукты

того, как создаются, компонуются и представляются входящие в нее

объекты
Входящие в семейство взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения
Система должна конфигурироваться одним из семейств составляющих ее объектов
Требуется предоставить библиотеку объектов, раскрывая только их интерфейсы, но не реализацию.

создающие конкретные объекты-продукты;
Объявляет интерфейс для типа объекта-продукта
Определяет объект-продукт, создаваемый

соответствующей конкретной фабрикой

Пользуется исключительно интерфейсами, которые объявлены в классах AbstractFactory и AbstractProduct

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

списки и т.п.
Их создание и работа с ними в различных ОС осуществляется по-разному
Чтобы приложение можно было легче перенести в другую ОС в нем не должно быть жесткой привязки к типам конкретных классов элементов управления
Паттерн «Абстрактная фабрика» облегчает решение данной задачи

: public CButton
{
//...
};

class CMacOSXButton : public CButton
{
//...
};
class CCheckBox
{
public:
virtual ~CCheckBox(){}
//

...
};

class CWindowsCheckBox : public CCheckBox
{
// ...
};

class CMacOSXCheckBox : public CCheckBox
{
// ...
};

CreateCheckBox()const=0;
};

class CWindowsUIFactory : public CUIFactory
{
public:
virtual CButton* CreateButton()const
{
return new CWindowsButton();
}
virtual

CCheckBox* CreateCheckCBox()const
{
return new CWindowsCheckBox();
}
};

class CMacOSXUIFactory : public CUIFactory
{
public:
virtual CButton* CreateButton()const
{
return new CMacOSXButton();
}
virtual CCheckBox* CreateCheckBox()const
{
return new CMacOSXCheckBox();
}
};

void BuildUI(CUIFactory const& uiFactory)
{
CButton * pOKButton = uiFactory.CreateButton();
CCheckBox * pCheckBox= uiFactory.CreateCheckBox();
}
int main(int argc, char* argv[])
{
CWindowsUIFactory uiFactory;
BuildUI(uiFactory);
return 0;
}

изолирует клиента от деталей реализации классов продуктов
Имена изготавливаемых классов

известны только конкретной фабрике, в коде клиента они не упоминаются
Клиенты манипулируют экземплярами продуктов только через их абстрактные интерфейсы
Упрощение замены семейств продуктов
Приложение может изменить семейство продуктов просто подставив новую конкретную фабрику
Гарантия сочетаемости продуктов
Если продукты спроектированы для совместного использования, важно чтобы в каждый момент времени приложение работало с продуктами единственного семейста

абстрактной фабрики фиксирует набор продуктов, которые можно создать
Для поддержки

новых продуктов необходимо расширить интерфейс фабрики, внеся изменения в класс AbstractFactory, а также во все его подклассы
Обход этого ограничения – передача идентификатора типа создаваемого продукта в методы фабрики, создающие продукты
Ограничение: создаваемые продукты должны поддерживать общий абстрактный интерфейс
Клиент не может различать типы продуктов и делать какие-либо предположения о них

IMapItem
{
public:
virtual ~IMapItem(){}
// ...
};
class CWall : public IMapItem {};
class CWater

: public IMapItem {};
class CForest : public IMapItem {};
class CSand : public IMapItem {};

class CMapItemsFactory
{
public:
IMapItem* CreateItem(ItemType type)const
{
switch (type)
{
case WALL: return new CWall();
case WATER: return new CWall();
case FOREST: return new CForest();
case SAND: return new CSand();
default:
throw new std::invalid_argument
("Unknown item type");
}
}
};

представления, так что в результате одного и того же

процесса конструирования могут получаться разные представления

должен зависеть от того, из каких частей состоит объект

и как они стыкуются между собой
Процесс конструирования должен обеспечивать различные представления конструируемого объекта

Builder, конструирует и собирает вместе части продукта
Определяет создаваемое представление

продукта и следит за ним
Предоставляет интерфейс для доступа к продукту

Конструирует продукт при помощи интерфейса Builder

Представляет сложный конструируемый объект
Включает классы, которые определяют составные части и интерфейсы для сборки конечного результата из частей

(Director) и конфигурирует его новым объектом-строителем Builder
Распорядитель уведомляет строителя

о необходимости построения очередной части продукта
Строитель обрабатывает запросы распорядителя и добавляет новые части к продукту
Клиент забирает продукт у строителя

абстрактный интерфейс Строителя, скрывающего структуру продукта и процесс сборки
Для

изменения внутреннего представления достаточно определить новую реализацию Строителя
Изолирует код, реализующий конструирование и представление
Клиенту не нужно знать о классах, задающих внутреннюю структуру продукта (в интерфейсе строителя они отсутствуют)
Дает более тонкий контроль над процессом конструирования
Процесс построения продукта происходит не сразу, как в других порождающих паттернах, а шаг за шагом

возможность преобразования его в различные форматы
Plain text, HTML, RTF,

PDF, DOC, DOCX
Список можно продолжить
Задача решается путем введения сущностей
Распорядитель - CFormattedTextReader
Строитель – CTextConverter
Конкретный Строитель – CHtmlConverter, CRTFConverter, CPlainTextConverter, CPDFConverter, …
Продукт – CPlainTextDocument, CHtmlDocument, CRTFDocument, CPDFDocument, …

void ConvertFontChange
(CFont const& fnt){}
// …
};

class CPlainTextConverter
: public CTextConverter
{
public:
void

ConvertText(std::string const& s)
{
// …
}
std::string const & GetPlainText()const
{
return m_plainText;
}
private:
std::string m_plainText;
};

class CPDFConverter
: public CTextConverter
{
public:
void ConvertText(std::string const& w)
{
// ...
}
void ConvertFontChange(CFont const& fnt)
{
// ...
}

CPDFDocument const& GetPDFDocument() const
{
return m_pdfDocument;
}
private:
CPDFDocument m_pdfDocument;
};

& converter)
{
for (size_t index = 0; index < text.GetItems();

++index)
{
CTextItem const & item = text.GetItem(index);
CTextRangeItem const* pTextRange = NULL;
CFontChangeCommand const& * pFontCommand = NULL;
if (pTextRange = dynamic_cast(&item))
{
converter.ConvertText(pTextRange->GetText());
}
else if (pFontCommand = dynamic_cast(&item))
{
converter.ConvertFontChange(pFontCommand->GetFont());
}
else if (…) { … } …
}
}
};