- •Гагарина. Л.Г., Федоров а.Р., Федоров п.А. Введение в архитектуру проектирования программного обеспечения Москва
- •Оглавление
- •5.11. Паттерны grasp
- •Глава 1. Архитектура как форма концептуального существования по
- •1.1. Определения архитектуры по и ее значимость
- •1.2. Место архитектурных решений
- •1.3. Роль архитектурных решений
- •1.4. Архитектурные концептуальные схемы. Определение и ретроспектива
- •Глава 2. Нормативные практики архитектурного описания по
- •2.1. Основные понятия
- •2.2. Содержание стандарта
- •2.3. Представления схемы ieee-1471
- •Глава 3. Рациональный процесс архитектурного моделирования
- •3.1. Архитектурные парадигмы
- •3.2. Примеры архитектурных стилей и моделей
- •Глава 4. Сравнительное сопоставление архитектурных видов
- •4.1. Сопоставление систем видов
- •4.2. Примеры систем видов
- •Языки описания архитектуры
- •Глава 5. Проектирование с учетом будущих изменений.
- •5.1. Что такое паттерн проектирования.
- •5.2. Как решать задачи проектирования с помощью паттернов
- •3. Зависимость от аппаратной и программной платформ.
- •5.4. Порождающие паттерны
- •5.4.1. Паттерн Фабричный метод (Factory Method) - уровень класса
- •Классический вариант фабричного метода, когда интерфейс фабричных методов объявляется в независимом классе-фабрике, а их реализация определяется конкретными подклассами этого класса (Рис. 33).
- •Реализация паттерна Factory Method на основе обобщенного конструктора
- •Void info() {
- •Void info() {
- •Void info() {
- •Int main()
- •V.Push_back( Warrior::createWarrior( Infantryman_id));
- •V.Push_back( Warrior::createWarrior( Archer_id));
- •V.Push_back( Warrior::createWarrior( Horseman_id));
- •Void info() {
- •Void info() {
- •Void info() {
- •Int main()
- •5.4.2. Паттерн Одиночка (Singleton) - уровень объекта
- •Классическая реализация Singleton
- •If(!p_instance)
- •Singleton Мэйерса
- •Улучшенная версия классической реализации Singleton
- •Void initialize( Singleton* p );
- •Void SingletonDestroyer::initialize( Singleton* p ) {
- •If(!p_instance) {
- •Использование нескольких взаимозависимых одиночек
- •Int main()
- •5.4.3. Паттерн Абстрактная фабрика (Abstract Factory) - уровень объекта
- •Пример кода для паттерна Abstract Factory
- •Void info() {
- •Int main()
- •5.4.4. Паттерн Строитель (Builder) - уровень объекта
- •Void info() {
- •Int main()
- •Infantryman
- •Infantryman
- •5.4.5. Паттерн Прототип (Prototype) - уровень объекта
- •Void info() {
- •Void info() {
- •5.4.6. Обсуждение порождающих паттернов
- •5.5. Структурные паттерны
- •5.5.1. Паттерн Адаптер, обертка (Adapter, wrapper)
- •Адаптер объекта применяет композицию объектов.
- •Int main()
- •Void adjust() {} // Настройка датчика (защищенный метод)
- •5.5.2. Паттерн Мост (Bridge)
- •Void log( string & str );
- •Достоинства паттерна Bridge
- •5.5.3. Паттерн компоновщик (Composite)
- •Описание паттерна Composite
- •Virtual void addUnit(Unit* p) {
- •Int main()
- •Virtual CompositeUnit* getComposite() {
- •Void addUnit(Unit* p);
- •Достоинства паттерна Composite
- •Недостатки паттерна Composite
- •5.5.4. Паттерн декоратор (Decorator , wrapper, обертка)
- •Реализация паттерна Decorator
- •Int width, height;
- •5.5.5. Паттерн фасад (Facade)
- •Void submitNetworkRequest()
- •If (_engineer.CheckOnStatus())
- •5.5.6. Паттерн приспособленец (Flyweight)
- •Структура паттерна приспособленец (Flyweight)
- •Icon(char *fileName)
- •Icon *FlyweightFactory::_icons[];
- •5.5.7 Паттерн заместитель (Proxy, surrogate, суррогат)
- •Void draw()
- •Int balance;
- •5.5.8. Обсуждение структурных паттернов
- •5.6. Паттерны поведения
- •5.6.1. ПаттернЦепочка обязанностей (Chain of Responsibility)
- •Void setNext(Base *n)
- •5.6.2. Паттерн Command (команда)
- •Реализация паттерна Command
- •5.6.3. Паттерн Interpreter (интерпетатор)
- •Совместное использование паттернов Interpreter и Template Method
- •Int interpret(char*); // interpret() for client
- •Virtual void interpret(char *input, int &total)
- •Int index;
- •If (!strncmp(input, nine(), 2))
- •Virtual char one(){}
- •Int items[10];
- •Int main()
- •5.6.5. Паттерн Mediator (посредник)
- •Virtual void changed();
- •Void Widget::changed()
- •Int main()
- •5.6.6. Паттерн Memento (хранитель)
- •Int _state;
- •Void static redo()
- •Int main()
- •Integer: 11
- •5.6.7. Паттерн Observer (наблюдатель)
- •Int value;
- •5.6.8. Паттерн State
- •Void setCurrent(State *s)
- •5.6.9. Паттерн Strategy
- •Void compress( const string & file ) {
- •5.6.10. Паттерн Template Method (шаблонный метод)
- •Void a()
- •V.Visit(this);
- •V.Visit(this);
- •V.Visit(this);
- •Int main()
- •5.6.12. Обсуждение паттернов поведения
- •5.7. Дальнейшее развитие идеи паттернов проектирования
- •5.8. Архитектурные системные паттерны
- •5.9. Паттерны управления
- •5.9.1. Паттерны централизованного управления
- •5.10. Паттерны интеграции корпоративных информационных систем
- •5.10.1. Структурные паттерны интеграции
- •5.10.2. Паттерны по методу интеграции
- •5.10.3. Паттерны интеграции по типу обмена данными
- •5.12. Антипаттерны (anti-patterns)
- •Глава 6. Архитектура и характеристики качества
- •6.1. Специфика требований к качеству по
- •6.2. Подход к построению архитектуры с позиций качества
- •6.3. Подходы к оцениванию архитектуры
5.4. Порождающие паттерны
Создание новых объектов является наиболее распространенной задачей, встающей перед разработчиками программных систем. Порождающие паттерны проектирования предназначены для создания объектов, позволяя системе оставаться независимой как от самого процесса порождения, так и от типов порождаемых объектов. Прежде чем рассматривать особенности каждого из порождающих паттернов, рассмотрим на примере типичные проблемы, встающие перед разработчиками при порождении в системе объектов новых типов на примере разработки стратегической игры под названием "Пунические войны", описывающую военное противостояние между Римской Республикой и Карфагеном (264 — 146 г. до н. э.) [17].
Персонажами игры могут быть воины трех типов: пехота, конница и лучники. Каждый из этих типов воинов обладает своими отличительными характеристиками, такими как внешний вид, боевая мощь, скорость передвижения и степень защиты. Несмотря на эти отличия, у всех видов боевых единиц есть общие черты. Например, все они могут передвигаться по игровому полю в различных направлениях, хотя всадники делают это быстрее всех. Каждая боевая единица имеет свой уровень здоровья, и если он становится равным нулю, воин погибает.
Мы изначально закладываем возможность развивать игру дальше. Например, мы планируем добавить новые виды воинов, такие как боевые слоны, усовершенствовать существующие, разделив пехоту на легковооруженных и тяжеловооруженных пехотинцев. Для внесения подобных изменений без модификации существующего кода, мы должны на этапе формирования архитектуры программы постараться сделать игру максимально независимой от конкретных типов персонажей. Ниже на примерах будут показаны способы практической реализации таких изменений без серьезной переделки как архитектуры так и кода ПО.
Порождающие паттерны проектирования позволяют сделать процесс инстанцирования абстрактным. Они помогают сделать систему независимой от способа создания, композиции и представления объектов.
Паттерны, порождающие классы, используют наследование, чтобы варьировать инстанцируемый класс, а паттерны, порождающие объекты, делегируют инстанцирование другому объекту.
Эти паттерны оказываются важны, когда система больше зависит от композиции объектов, чем от наследования классов. Оновной упор делается не на жестком кодировании фиксированного набора поведений, а на определении небольшого набора фундаментальных поведений, с помощью композиции которых можно получать любое число более сложных поведений. Таким образом, для создания объектов с конкретным поведением требуется нечто большее, чем простое инстанцирование класса.
Для порождающих паттернов важно следующее. Во-первых, эти паттерны инкапсулируют знания о конкретных классах, которые применяются в системе. Во-вторых, скрывают детали того, как эти классы создаются и стыкуются. Единственная информация об объектах, известная системе, - это их интерфейсы, определенные с помощью абстрактных классов. Следовательно, порождающие паттерны обеспечивают большую гибкость при решении вопроса о том, что создается, кто это создает, как и когда. Систему можно собирать из ≪готовых≫ объектов с самой различной структурой и функциональностью статически (на этапе компиляции) или динамически (во время выполнения).
