Графика
<<  Через сквозное проектирование - к cals-технологиям Техника проведения лабораторных работ по нефти  >>
Фабричный метод [ Factory Method ] Применимость:
Фабричный метод [ Factory Method ] Применимость:
Фабричный метод [ Factory Method ] Применимость:
Фабричный метод [ Factory Method ] Применимость:
Фабричный метод [ Factory Method ] Двойная иерархия:
Фабричный метод [ Factory Method ] Двойная иерархия:
Абстрактная фабрика [ Abstract Factory ] Структура:
Абстрактная фабрика [ Abstract Factory ] Структура:
Прототип [ Prototype ] Проблематика:
Прототип [ Prototype ] Проблематика:
Строитель [ Builder ] Проблематика:
Строитель [ Builder ] Проблематика:
Строитель [ Builder ] Применимость:
Строитель [ Builder ] Применимость:
Строитель [ Builder ] Отношения:
Строитель [ Builder ] Отношения:
Одиночка [ Singleton ] Проблематика:
Одиночка [ Singleton ] Проблематика:
Картинки из презентации «Типовые решения проектирования» к уроку черчения на тему «Графика»

Автор: zmeyev oa. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока черчения, скачайте бесплатно презентацию «Типовые решения проектирования.ppt» со всеми картинками в zip-архиве размером 331 КБ.

Типовые решения проектирования

содержание презентации «Типовые решения проектирования.ppt»
Сл Текст Сл Текст
1Лекция № 9 Типовые решения 29операцию клонирования себя; Client
проектирования. Порождающие паттерны. (GraphicTool) - клиент: - создает новый
2Основная цель: независимость процесса объект, обращаясь к прототипу с запросом
инициализации объектов. Система становится клонировать себя. Отношения: Клиент
независимой от способа создания, обращается к прототипу, чтобы тот создал
композиции и представления объектов. свою копию. Прототип [ Prototype ]
Особенности: Система зависит от композиции Участники и отношения:
классов, а не от иерархии наследования. 30Прототип [ Prototype ] Результаты: У
Основной упор делается не на определении и прототипа те же самые результаты, что у
кодировании фиксированного набора абстрактной фабрики и строителя: он
поведений, а на определении некоторого скрывает от клиента конкретные классы
базового множества поведений, комбинируя продуктов, уменьшая тем самым число
которые можно получить все, что нужно. Для известных клиенту имен. Кроме того, все
создания объектов с конкретным поведением эти паттерны позволяют клиентам работать
требуется нечто большее, чем простая со специфичными для приложения классами
инициализация. без модификаций. Дополнительные
3Порождающие паттерны. Две характерные преимущества паттерна прототип: Основной
особенности: Инкапсуляция знаний о недостаток паттерна прототип заключается в
конкретных классах, которые применяются в том, что каждый подкласс класса Prototype
системе. Скрываются детали того, каким должен реализовывать операцию Clone, а это
образом эти классы создаются и стыкуются. далеко не всегда просто. Например, сложно
Единственная информация, которая доступна добавить операцию Clone, когда
системе – это интерфейсы объектов, которые рассматриваемые классы уже существуют.
определяются с помощью абстрактных Проблемы возникают и в случае, если во
классов. Таким образом получаем ответы на внутреннем представлении объекта есть
следующие вопросы: что создается, кто другие объекты или наличествуют круговые
создает, и когда. В результате можно ссылки. добавление и удаление продуктов во
собрать систему из готовых объектов с время выполнения. Прототип позволяет
самой различной структурой либо включать новый конкретный класс продуктов
статически, либо динамически. в систему, просто сообщив клиенту о новом
4Порождающие паттерны Список и краткие экземпляре-прототипе. Это несколько более
характеристики: Фабричный метод [ Factory гибкое решение по сравнению с тем, что
Method ] – определяет интерфейс для удастся сделать с помощью других
создания объектов, при этом порождающих паттернов, ибо клиент может
непосредственное создание объектов устанавливать и удалять прототипы во время
выполняется подклассами. Абстрактная выполнения;
фабрика [ Abstract Factory ] – 31Прототип [ Prototype ] Результаты:
представляет интерфейс для создания спецификация новых объектов путем
семейств связанных между собой или изменения значений. Динамичные системы
независимых объектов, конкретные классы позволяют определять поведение за счет
которых неизвестны. Строитель [ Builder ] композиции объектов - например, путем
– отделяет сборку сложного объекта от его задания значений переменных объекта, - а
представления, позволяет использовать один не с помощью определения новых классов. По
и тот же процесс конструирования для сути дела, вы определяете новые виды
создания различных представлений. Прототип объектов, инициализируя уже существующие
[ Prototype ] – описывает виды создаваемых классы и регистрируя их экземпляры как
объектов путем прототипа, инициализирует прототипы клиентских объектов. Клиент
новый объект путем копирования прототипа. может изменить поведение, делегируя свои
Одиночка [ Singleton ] – гарантирует, что обязанности прототипу. Такой дизайн
некоторый класс будет представлен в виде позволяет пользователям определять новые
единственного экземпляра и предоставляет классы без программирования. Фактически
точку доступа к этому экземпляру. клонирование объекта аналогично
5Фабричный метод [ Factory Method ] инициализации класса. Паттерн прототип
Проблематика: Каркасы пользуются может резко уменьшить число необходимых
абстрактными классами для определения и системе классов, В нашем редакторе с
поддержания отношений между объектами. помощью одного только класса GraphicTool
Кроме того, каркас часто отвечает за удастся создать бесконечное разнообразие
создание самих объектов. Рассмотрим каркас армейских объектов;
для приложений, способных представлять 32специфицирование новых объектов путем
пользователю сразу несколько документов. изменения структуры. Многие приложения
Две основных абстракции в таком каркасе - строят объекты из крупных и мелких
это классы Application и Document. Оба составляющих. Например, редакторы для
класса абстрактные, поэтому клиенты должны проектирования печатных плат создают
порождать от них подклассы для создания электрические схемы из подсхем (для таких
специфичных для приложения реализаций. приложений характерны паттерны компоновщик
Например, чтобы создать приложение для и декоратор). Такие приложения часто
рисования, мы определим классы позволяют инициализировать сложные,
DrawingApplication и DrawingDocument. определенные пользователем структуры,
Класс Application отвечает за управление скажем, для многократного использования
документами и создает их по мере некоторой подсхемы. Паттерн прототип
необходимости, допустим, когда поддерживает и такую возможность. Мы
пользователь выбирает из меню пункт Open просто добавляем подсхему как прототип в
(открыть) или New (создать). палитру доступных элементов схем. При
6Фабричный метод [ Factory Method ] условии, что объект, представляющий
Проблематика: Поскольку решение о том, составную схему, реализует операцию Clone
какой подкласс класса Document как глубокое копирование, схемы с разными
инициализировать, зависит от приложения, структурами могут выступать в качестве
то Application не может прототипов; Прототип [ Prototype ]
"предсказать", что именно Результаты:
понадобится. Этому классу известно лишь, 33Прототип [ Prototype ] Результаты:
когда нужно инициализировать новый уменьшение числа подклассов. Паттерн
документ, а не какой документ создать. фабричный метод часто порождает иерархию
Возникает дилемма: каркас должен классов Creator, параллельную иерархии
инициализировать классы, но классов продуктов. Прототип позволяет
"знает" он лишь об абстрактных клонировать прототип, а не запрашивать
классах, которые создавать нельзя. Решение фабричный метод создать новый объект.
предлагает паттерн фабричный метод. В нем Поэтому иерархия класса Creator становится
инкапсулируется информация о том, какой вообще ненужной; динамическое
подкласс класса Document создать, и это конфигурирование приложения классами.
знание выводится за пределы каркаса. Некоторые среды позволяют динамически
Подклассы класса Application загружать классы в приложение во время его
переопределяют абстрактную операцию выполнения. Паттерн прототип - это ключ к
CreateDocument таким образом, чтобы она применению таких возможностей в языке типа
возвращала подходящий подкласс класса C++. Приложение, которое создает
Document. Как только подкласс Application экземпляры динамически загружаемого
создан, он может инициализировать класса, не может обращаться к его
специфические для приложения документы, конструктору статически. Вместо этого
ничего не зная об их классах. Операцию исполняющая среда автоматически создает
CreateDocument мы называем фабричным экземпляр каждого класса в момент его
методом, поскольку она отвечает за загрузки и регистрирует экземпляр в
"изготовление" объекта. диспетчере прототипов (см. раздел
7Фабричный метод [ Factory Method ] «Реализация»). Затем приложение может
Применимость: запросить у диспетчера прототипов
8Классу заранее неизвестно, объекты экземпляры вновь загруженных классов,
каких классов ему нужно создавать; класс которые изначально не были связаны с
спроектирован так, чтобы объекты, которые программой.
он создает, специфицировались подклассами; 34Прототип [ Prototype ] Некоторые
класс делегирует свои обязанности одному полезные приемы реализации: использование
из нескольких вспомогательных подклассов, диспетчера прототипов. Если число
и вы планируете локализовать знание о том, прототипов в системе не фиксировано (то
какой класс принимает эти обязанности на есть они могут создаваться и уничтожаться
себя. Фабричный метод [ Factory Method ] динамически), ведите реестр доступных
Применимость: прототипов. Клиенты должны не управлять
9Фабричный метод [ Factory Method ] прототипами самостоятельно, а сохранять и
Применимость: извлекать их из реестра. Клиент
10Фабричный метод [ Factory Method ] запрашивает прототип из реестра перед его
Участники: Product (Document) - Продукт: - клонированием. Такой реестр называют
определяет интерфейс объектов, создаваемых диспетчером прототипов. Диспетчер
фабричным методом; ConcreteProduct прототипов - это ассоциативное хранилище,
(MyDocument) - конкретный продукт: - которое возвращает прототип,
реализует интерфейс Product; Creator соответствующий заданному ключу. В нем
(Application) - создатель: - объявляет есть операции для регистрации прототипа с
фабричный метод, возвращающий объект типа указанным ключом и отмены регистрации.
Product. Creator может также определять Клиенты могут изменять и даже
реализацию по умолчанию фабричного метода, «просматривать реестр во время выполнения,
который возвращает объект; ConcreteCreator а значит, расширять систему и вести
(MyApplication) - конкретный создатель: - контроль над ее состоянием без написания
замещает фабричный метод, возвращающий кода;
объект Concrete Product. Отношения 35Прототип [ Prototype ] Некоторые
Создатель "полагается" на свои полезные приемы реализации: реализация
подклассы в определении фабричного метода, операции Clone. Самая трудная часть
который будет возвращать экземпляр паттерна прототип - правильная реализация
подходящего конкретного продукта. операции clone. Особенно сложно это в
11Фабричный метод [ Factory Method ] случае, когда в структуре объекта есть
Результаты: Фабричные методы избавляют круговые ссылки. В большинстве языков
проектировщика от необходимости встраивать имеется некоторая поддержка для
в код зависящие от приложения классы. Код клонирования объектов. Но эти средства не
имеет дело только с интерфейсом класса решают проблему "глубокого и
Product, поэтому он может работать с поверхностного копирования". Суть ее
любыми определенными пользователями в следующем: должны ли при клонировании
классами конкретных продуктов. объекта клонироваться также и его
Потенциальный недостаток фабричного метода переменные экземпляра или клон просто
состоит в том, что клиентам, возможно, разделяет с оригиналом эти переменные?
придется создавать подкласс класса Creator Поверхностное копирование просто, и часто
для создания лишь одного объекта его бывает достаточно. Но для клонирования
ConcreteProduct. Порождение подклассов прототипов со сложной структурой обычно
оправдано, если клиенту так или иначе необходимо глубокое копирование, поскольку
приходится создавать подклассы Creator, в клон должен быть независим от оригинала.
противном случае клиенту придется иметь Поэтому нужно гарантировать, что
дело с дополнительным уровнем подклассов. компоненты клона являются клонами
Фабричный метод предоставляет подклассам компонентов прототипа. При клонировании
операции-зацепки (hooks). Создание вам приходится решать, что именно может
объектов внутри класса с помощью разделяться и может ли вообще. Если
фабричного метода всегда оказывается более объекты в системе предоставляют операции
гибким решением, чем непосредственное Save (сохранить) и Load (загрузить), то
создание. Фабричный метод создает в разрешается воспользоваться ими для
подклассах операции-зацепки для реализации операции Clone по умолчанию,
предоставления расширенной версии объекта. просто сохранив и сразу же загрузив
В примере с документом класс Document мог объект. Операция Save сохраняет объект в
бы определить фабричный метод буфере памяти, a Load создает дубликат,
CreateFileDialog, который создает реконструируя объект из буфера;
диалоговое окно для выбора файла 36Прототип [ Prototype ] Некоторые
существующего документа. Подкласс этого полезные приемы реализации: инициализация
класса мог бы определить клонов. Хотя некоторым клиентам вполне
специализированное для приложения достаточно клона как такового, другим
диалоговое окно, заместив этот фабричный нужно инициализировать его внутреннее
метод. В данном случае фабричный метод не состояние полностью или частично. Обычно
является абстрактным, . а содержит передать начальные значения операции Clone
разумную реализацию по умолчанию. невозможно, поскольку их число различно
12Фабричный метод соединяет параллельные для разных классов прототипов. Для
иерархии. В примерах, которые мы некоторых прототипов нужно много
рассматривали до сих пор, фабричные методы параметров инициализации, другие вообще
вызывались только создателем. Но это ничего не требуют. Передача Clone
совершенно необязательно: клиенты тоже параметров мешает построению
могут применять фабричные методы, особенно единообразного интерфейса клонирования.
при наличии параллельных иерархий классов. Может оказаться, что к ваших классах
Параллельные иерархии возникают в случае, прототипов уже определяются операции для
когда класс делегирует часть своих установки и очистки некоторых важных
обязанностей другому классу, не элементов состояния. Если так, то этими
являющемуся производным от него. операциями можно воспользоваться сразу
Рассмотрим, например, графические фигуры, после клонирования. В противном случае,
которыми можно манипулировать возможно, понадобится ввести операцию
интерактивно: растягивать, двигать или Initialize, которая принимает начальные
вращать с помощью мыши. Реализация таких значения в качестве аргументов и
взаимодействий с пользователем - не всегда соответственно устанавливает внутреннее
простое дело. Часто приходится сохранять и состояние клона. Будьте осторожны, если
обновлять информацию о текущем состоянии операция clone реализует глубокое
манипуляции. Но это состояние нужно только копирование: копии может понадобиться
во время самой манипуляции, поэтому удалять (явно или внутри Initialize) перед
помещать его в объект, повторной инициализацией.
представляющий-фигуру, не следует. К тому 37Строитель [ Builder ] Проблематика:
же фигуры ведут себя по-разному, когда Программа, в которую заложена возможность
пользователь манипулирует ими. Например, распознавания и чтения документа в формате
растягивание отрезка может сводиться к RTF (Rich Text Format), должна также
изменению положения концевой точки, а "уметь" преобразовывать его во
растягивание текста - к изменению многие другие форматы. Однако число
междустрочных интервалов. При таких вероятных преобразований заранее
ограничениях лучше использовать отдельный неизвестно. Поэтому должна быть обеспечена
объект-манипулятор Manipulator, который возможность без труда добавлять новый
реализует взаимодействие и контролирует конвертор. Таким образом, нужно
его текущее состояние. У разных фигур сконфигурировать класс RTFReader с помощью
будут разные манипуляторы, являющиеся объекта TextConverter, который мог бы
подклассом Manipulator. Получающаяся преобразовывать RTF в другой текстовый
иерархия класса Manipulator параллельна формат. При разборе документа в формате
(по крайней мере, частично) иерархии RTF класс RTFReader вызывает TextConverter
класса Figure. Класс Figure предоставляет для выполнения преобразования. Всякий раз,
фабричный метод CreateManipulator, который как RTFReader распознает лексему RTF
позволяет клиентам создавать (простой текст или управляющее слово), для
соответствующий фигуре манипулятор. ее преобразования объекту TextConverter
Подклассы Figure замещают этот метод так, посылается запрос. Объекты TextConverter
чтобы он возвращал подходящий для них отвечают как за преобразование данных, так
подкласс Manipulator. Вместо этого класс и за представление лексемы в конкретном
Figure может реализовать CreateManipulator формате. Подклассы TextConverter
так, что он будет возвращать экземпляр специализируются на различных
класса Manipulator по умолчанию, а преобразованиях и форматах. Класс каждого
подклассы Figure могут наследовать это конвертора принимает механизм создания и
умолчание. Те классы фигур, которые сборки сложного объекта и скрывает его за
функционируют по описанному принципу, не абстрактным интерфейсом. Конвертор отделен
нуждаются в специальном манипуляторе, от загрузчика, который отвечает за
поэтому иерархии параллельны только синтаксический разбор RTF-документа. В
отчасти. паттерне строитель абстрагированы все эти
13Фабричный метод [ Factory Method ] отношения. В нем любой класс конвертора
Двойная иерархия: называется строителем, а загрузчик -
14Реализация: две основных разновидности распорядителем..
паттерна. Во-первых, это случай, когда 38Строитель [ Builder ] Проблематика:
класс Creator является абстрактным и не 39Строитель [ Builder ] Применимость:
содержит реализации объявленного в нем Алгоритм создания сложного объекта не
фабричного метода. Вторая возможность: должен зависеть от того, из каких частей
Creator — конкретный класс, в котором по состоит объект и как они стыкуются между
умолчанию есть реализация фабричного собой; процесс конструирования должен
метода. Редко, но встречается и обеспечивать различные представления
абстрактный класс, имеющий реализацию по конструируемого объекта.
умолчанию; В первом случае для определения 40Строитель [ Builder ] Участники и
реализации необходимы подклассы, поскольку отношения: Участники: Builder
никакого разумного умолчания не (TextConverter) -строитель: - задает
существует. При этом обходится проблема, абстрактный интерфейс для создания частей
связанная с необходимостью инсталлировать объекта Product; ConcreteBuilder
заранее неизвестные классы. Во втором (ASCIIConverter,TeXConverter,TextWidgetCon
случае конкретный класс Creator использует erter)-конкретный строитель: -
фабричный метод, главным образом ради конструирует и собирает вместе части
повышения гибкости. Выполняется правило: продукта посредством реализации интерфейса
«Создавай объекты в отдельной операции, Builder; - определяет создаваемое
чтобы подклассы могли подменить способ их представление и следит за ним; -
создания». Соблюдение этого правила предоставляет интерфейс для доступа к
гарантирует, что авторы подклассов смогут продукту (например,
при необходимости изменить класс объектов, GetASCIIText,GetTextWidget); Director
инстанцируемых их родителем; (RTFReader) - распорядитель: -
параметризованные фабричные методы. Это конструирует объект, пользуясь интерфейсом
еще один вариант паттерна, который Builder; Product (ASCIIText, TeXText,
позволяет фабричному методу создавать TextWidget) - продукт: - представляет
разные виды продуктов. Фабричному методу сложный конструируемый объект.
передается параметр, который ConcreteBuilder строит внутреннее
идентифицирует вид создаваемого объекта. представление продукта и определяет
Все объекты, получающиеся с помощью процесс его сборки; - включает классы,
фабричного метода, разделяют общий которые определяют составные части, в том
интерфейс Product. В примере с документами числе интерфейсы для сборки конечного
класс Application может поддерживать результата из частей.
разные виды документов. Вы передаете 41Строитель [ Builder ] Участники и
методу GreateDocument лишний параметр, отношения: Отношения: клиент создает
который и определяет, документ какого вида объект-распорядитель Director и
нужно создать. конфигурирует его нужным
15Абстрактная фабрика [ Abstract Factory объектом-строителем Builder; распорядитель
] Проблематика: Вернемся теперь к нашей уведомляет строителя о том, что нужно
мега крутой игре. Предположим, что наша построить очередную часть продукта;
игра должна поддерживать разные стандарты строитель обрабатывает запросы
внешнего вида для городов, заселенных распорядителя и добавляет новые части к
различными расами (например, города орков продукту; клиент забирает продукт у
должны быть городами орков, а города строителя.
андедов – андедскими). Внешний вид при 42Строитель [ Builder ] Отношения:
этом определяет визуальное представление и 43Строитель [ Builder ] Результаты:
поведение элементов интерфейса позволяет изменять внутреннее
пользователя – здания, окна, кнопки и т.д. представление продукта. Объект Builder
и т.п. Чтобы в наше приложение можно было предоставляет распорядителю абстрактный
легко добавлять новые расы (например, интерфейс для конструирования продукта, за
белых пушистых кроликов) мы должны которым он может скрыть представление и
отказать от жесткой привязки к внутреннюю структуру продукта, а также
соответствующим элементам интерфейса. Тем процесс его сборки. Поскольку продукт
более мы должны избегать ситуации, когда конструируется через абстрактный
инициализация элементов города будет интерфейс, то для изменения внутреннего
разбросана по приложению (например, орочьи представления достаточно всего лишь
города строятся в орочьих модулях, а определить новый вид строителя; изолирует
андедовские в андедовских). Давайте код, реализующий конструирование и
разберем один из способов решения этой представление. Паттерн строитель улучшает
проблемы. модульность, инкапсулируя способ
16Абстрактная фабрика [ Abstract Factory конструирования и представления сложного
] Применимость: объекта. Клиентам ничего не надо знать о
17Абстрактная фабрика [ Abstract Factory классах, определяющих внутреннюю структуру
] Применимость: Система не должна зависеть продукта, они отсутствуют в интерфейсе
от того, как создаются, компонуются, строителя. Каждый конкретный строитель
компонуются и представляются входящие в ConcreteBuilder содержит весь код,
нее объекты входящие в семейство необходимый для создания и сборки
взаимосвязанные объекты должны конкретного вида продукта. Код пишется
использоваться вместе и вам необходимо только один раз, после чего разные
обеспечить выполнение этого ограничения распорядители могут использовать его
система должна конфигурироваться одним из повторно для построения вариантов продукта
семейств составляющих ее объектов вы из одних и тех же частей. В примере с
хотите предоставить библиотеку объектов, RTF-документом мы могли бы определить
раскрывая только их интерфейсы, но не загрузчик для формата, отличного от RTF,
реализацию. скажем, SGMLReader, и воспользоваться теми
18Абстрактная фабрика [ Abstract Factory же самыми классами TextConverters для
] Структура: генерирования представлений
19Участники: AbstractFactory SGML-документов в виде ASCII-текста,
(TownFactory) - абстрактная фабрика: ТеХ-текста или текстового виджета;
объявляет интерфейс для операций, 44Строитель [ Builder ] Результаты: дает
создающих абстрактные объекты-продукты; более тонкий контроль над процессом
CocreteFactory (OrcTownFactory, конструирования. В отличие от порождающих
UndeadTownFactory) - конкретная фабрика - паттернов, которые сразу конструируют весь
реализует операции, создающие конкретные объект целиком, строитель делает это шаг
объекты-продукты; AbstractProduct за шагом под управлением распорядителя. И
(TownCentre, Button) - абстрактный лишь когда продукт завершен, распорядитель
продукт, объявляет интерфейс для типа забирает его у строителя. Поэтому
объекта-продукта; ConcreteProduct интерфейс строителя в большей степени
(OrcTownCentre, OrcButton, отражает процесс конструирования продукта,
UndeadTownCentre, UndeadButton) - нежели другие порождающие паттерны. Это
конкретный продукт: - определяет позволяет обеспечить более тонкий контроль
объект-продукт, создаваемый над процессом конструирования, а значит, и
соответствующей конкретной фабрикой; - над внутренней структурой готового
реализует интерфейс AbstractProduct; продукта. Реализация: Обычно существует
Client – клиент, пользуется исключительно абстрактный класс Builder, в котором
интерфейсами, которые объявлены в классах определены операции для каждого
AbstractFactory и AbstractProduct. компонента, который распорядитель может
Отношения Обычно во время выполнения «попросить» создать. По умолчанию эти
создается единственный экземпляр класса операции ничего не делают. Но в классе
ConcreteFactory. Эта конкретная фабрика конкретного строителя ConcreteBuilder они
создает объекты-продукты, имеющие вполне замещены для тех компонентов, в создании
определенную реализацию. Для создания которых он принимает участие.
других видов объектов клиент должен 45Строитель [ Builder ] Реализация: Вот
воспользоваться другой конкретной еще некоторые достойные внимания вопросы
фабрикой; AbstractFactory передоверяет реализации: интерфейс сборки и
создание объектов-продуктов своему конструирования. Строители конструируют
подклассу ConcreteFactory. свои продукты шаг за шагом. Поэтому
20Абстрактная фабрика (Abstract Factory интерфейс класса Builder должен быть
) Результаты: Обладает следующими плюсами достаточно общим, чтобы обеспечить
и минусами: изолирует конкретные классы. конструирование при любом виде конкретного
Помогает контролировать классы объектов, строителя. Ключевой вопрос проектирования
создаваемых приложением. Поскольку фабрика связан с выбором модели процесса
инкапсулирует ответственность за создание конструирования и сборки. Обычно бывает
классов и сам процесс их создания, то она достаточно модели, в которой результаты
изолирует клиента от деталей реализации выполнения запросов на конструирование
классов. Клиенты манипулируют экземплярами просто добавляются к продукту. В примере с
через их абстрактные интерфейсы. Имена RTF-документом строитель преобразует и
изготавливаемых классов известны только добавляет очередную лексему к уже
конкретной фабрике, в коде клиента они не конвертированному тексту. Но иногда может
упоминаются; упрощает замену семейств потребоваться доступ к частям
продуктов. Класс конкретной фабрики сконструированного к данному моменту
появляется в приложении только один раз: продукта. Другим примером являются
при инициализации. Это облегчает замену древовидные структуры, скажем, деревья
используемой приложением конкретной синтаксического разбора, которые строятся
фабрики. Приложение может изменить снизу вверх. В этом случае строитель
конфигурацию продуктов, просто подставив должен был бы вернуть узлы-потомки
новую конкретную фабрику. Поскольку распорядителю, который затем передал бы их
абстрактная фабрика создает все семейство назад строителю, чтобы тот мог построить
продуктов, то и заменяется сразу все родительские узлы.
семейство. В нашем примере перейти от 46Строитель [ Builder ] Реализация:
зданий Орков к зданиям Андедов можно, почему нет абстрактного класса для
просто переключившись на продукты продуктов. В типичном случае продукты,
соответствующей фабрики и заново создав изготавливаемые различными строителями,
интерфейс; имеют настолько разные представления, что
21Абстрактная фабрика (Abstract Factory изобретение для них общего родительского
) Результаты: гарантирует сочетаемость класса ничего не дает. В примере с
продуктов. Если продукты некоторого RTF-документами трудно представить себе
семейства спроектированы для совместного общий интерфейс у объектов ASCIIText и
использования, то важно, чтобы приложение TextWidget, да он и не нужен. Поскольку
в каждый момент времени работало только с клиент обычно конфигурирует распорядителя
продуктами единственного семейства. Класс подходящим конкретным строителем, то, надо
AbstractFactory позволяет легко соблюсти полагать, ему известно, какой именно
это ограничение; поддержать новый вид подкласс класса Builder используется и как
продуктов трудно. Расширение абстрактной нужно обращаться с произведенными
фабрики для изготовления новых видов продуктами; пустые методы класса Builder
продуктов - непростая задача. Интерфейс no умолчанию. В C++ методы строителя
AbstractFactory фиксирует набор продуктов, намеренно не объявлены чисто виртуальными
которые можно создать. Для поддержки новых функциями-членами. Вместо этого они
продуктов необходимо расширить интерфейс определены как пустые функции, что
фабрики, то есть изменить класс позволяет подклассу замешать только те
AbstractFactory и все его подклассы. операции, в которых он заинтересован.
Решение этой проблемы мы обсудим в разделе 47Одиночка [ Singleton ] Проблематика:
"Реализация". Для некоторых классов важно, чтобы
22Абстрактная фабрика (Abstract Factory существовал только один экземпляр. Хотя в
) Некоторые полезные приемы реализации: системе может быть много принтеров, но
фабрики как объекты, существующие в возможен лишь один менеджер. Должны быть
единственном экземпляре. Как правило, только одна файловая система и
приложению нужен только один экземпляр единственный оконный менеджер. В цифровом
класса ConcreteFactory на каждое семейство фильтре может находиться только один
продуктов. Поэтому для реализации лучше аналого-цифровой преобразователь (АЦП).
всего применить паттерн одиночка; создание Бухгалтерская система обслуживает только
продуктов. Класс AbstractFactory объявляет одну компанию. Как гарантировать, что у
только интерфейс для создания продуктов. класса есть единственный экземпляр и что
Фактическое их создание - дело подклассов этот экземпляр легко доступен? Глобальная
ConcreteProduct. Чаще всего для этой цели переменная дает доступ к объекту, но не
определяется фабричный метод для каждого запрещает инициализировать класс в
продукта (см. паттерн фабричный метод). нескольких экземплярах. Более удачное
Конкретная фабрика специфицирует свои решение - сам класс контролирует то, что у
продукты путем замещения фабричного метода него есть только один экземпляр, может
для каждого из них. Хотя такая реализация запретить создание дополнительных
проста, она требует создавать новый экземпляров, перехватывая запросы на
подкласс конкретной фабрики для каждого создание новых объектов, и он же способен
семейства продуктов, даже если они почти предоставить доступ к своему экземпляру.
ничем не отличаются. Это и есть назначение паттерна одиночка.
23Абстрактная фабрика (Abstract Factory 48Одиночка [ Singleton ] Проблематика:
) Некоторые полезные приемы реализации: Должен быть ровно один экземпляр
Если семейств продуктов может быть много, некоторого класса, легко доступный всем
то конкретную фабрику удастся реализовать клиентам; единственный экземпляр должен
с помощью паттерна прототип. В этом случае расширяться путем порождения подклассов, и
она инициализируется клиентам нужно иметь возможность работать
экземпляром-прототипом каждого продукта в с расширенным экземпляром без модификации
семействе и создает новый продукт путем своего кода.
клонирования этого прототипа. Подход на 49Одиночка [ Singleton ] Участники и
основе прототипов устраняет необходимость отношения: Участники: Singleton -
создавать новый класс конкретной фабрики одиночка: - определяет операцию Instance,
для каждого нового семейства продуктов. В которая позволяет клиентам получать доступ
языках, где сами классы являются к единственному экземпляру. Instance - это
настоящими объектами (например, Smalltalk операция класса, то есть метод класса в
и Objective С), возможны некие вариации терминологии Smalltalk и статическая
подхода на базе прототипов. В таких языках функция-член в C++; - может нести
класс можно представлять себе как ответственность за создание собственного
вырожденный случай фабрики, умеющей уникального экземпляра. Отношения: Клиенты
создавать только один вид продуктов. Можно получают доступ к экземпляру класса
хранить классы внутри конкретной фабрики, singleton только через его операцию.
которая создает разные конкретные продукты 50Одиночка [ Singleton ] Участники и
в переменных. Это очень похоже на отношения: Отношения: клиент создает
прототипы. Такие классы создают новые объект-распорядитель Director и
экземпляры от имени конкретной фабрики. конфигурирует его нужным
Новая фабрика инициализируется экземпляром объектом-строителем Builder; распорядитель
конкретной фабрики с классами продуктов, а уведомляет строителя о том, что нужно
не путем порождения подкласса. Подобный построить очередную часть продукта;
подход задействует некоторые специфические строитель обрабатывает запросы
свойства языка, тогда как подход, распорядителя и добавляет новые части к
основанный на прототипах, от языка не продукту; клиент забирает продукт у
зависит. строителя.
24Прототип [ Prototype ] Проблематика: 51Одиночка [ Singleton ] Результаты: У
Мы продолжаем разрабатывать нашу паттерна одиночка есть определенные
супер-пупер игру. Реализуем функционал, достоинства: контролируемый доступ к
позволяющий пользователю создавать армию. единственному экземпляру. Поскольку класс
Предположим, что для этих целей мы Singleton инкапсулирует свой единственный
используем некоторую библиотеку, которая экземпляр, он полностью контролирует то,
позволяет работать с графическими как и когда клиенты получают доступ к
объектами. Нам необходимо добавить в эту нему; уменьшение числа имен. Паттерн
библиотеку новые объекты, представляющие одиночка - шаг вперед по сравнению с
воинов, героев, всадников, монстров и т.д. глобальными переменными. Он позволяет
Предположим, что у нас в библиотеке избежать засорения пространства имен
имеется возможность группировать объекты глобальными переменными, в которых
на некоторых панелях. Эта панель содержит хранятся уникальные экземпляры; допускает
инструменты для выбора, перемещения и иных уточнение операций и представления. От
манипуляции с объектами. Так, игрок, класса Singleton можно порождать
щелкнув, например, по пиктограмме героя подклассы, а приложение легко
помещает его в армию. А используя сконфигурировать экземпляром расширенного
инструмент перемещения формирует боевой класса. Можно конкретизировать приложение
порядок войск, перемещая их вверх или экземпляром того класса, который необходим
вниз. Предположим, что в библиотеке во время выполнения;
имеется: абстрактный класс Graphic для 52Одиночка [ Singleton ] Результаты:
графических компонентов вроде героев, допускает переменное число экземпляров.
солдат и т.д. также абстрактный класс Tool Паттерн позволяет нам легко изменить свое
для определения инструментов на панели решение и разрешить появление более одного
кроме того, имеется предопределенный экземпляра класса Singleton. Вы можете
подкласс GraphicTool для инструментов, применять один и тот же подход для
которые создают графические объекты и управления числом экземпляров,
добавляют их в документ. используемых в приложении. Изменить нужно
25Прототип [ Prototype ] Проблематика: будет лишь операцию, дающую доступ к
Однако класс GraphicTool создаст некую экземпляру класса singleton; большая
проблему для проектировщика библиотеки. гибкость, чем у операций класса. Еще один
Классы героев, солдат и монстров для способ реализовать функциональность
нашего приложения, а класс GraphicTool одиночки - использовать операции класса,
принадлежит библиотеке. Для того, чтобы то есть статические функции-члены в C++ и
его можно было использовать повторно, он методы класса в Smalltalk. Но оба этих
ничего не должен знать о том, как приема препятствуют изменению дизайна,
создавать экземпляры наших игровых классов если потребуется разрешить наличие
и добавлять их в армию. Можно было бы нескольких экземпляров класса. Кроме того,
породить от GraphicTool подклассы для статические функции-члены в C++ не могут
каждого вида наших объектов, по тогда быть виртуальными, так что их нельзя
оказалось бы слишком много классов, полиморфно заместить в подклассах.
отличающихся только тем, какой объект 53Одиночка [ Singleton ] Реализация:
армии они инсталлируют. Решение: заставить гарантирование единственного экземпляра.
GraphicTool создавать новый графический Паттерн одиночка устроен так, что тот
объект, копируя или "клонируя" единственный экземпляр, который имеется у
экземпляр подкласса класса Graphic. Этот класса, - самый обычный, но больше одного
экземпляр мы будем называть прототипом. экземпляра создать не удастся. Чаще всего
GraphicTool параметризуется прототипом, для этого прячут операцию, создающую
который он должен клонировать и добавить в экземпляры, за операцией класса (то есть
документ. Если все подклассы Graphic за статической функцией-членом или методом
поддерживают операцию Clone, то класса), которая гарантирует создание не
GraphicTool может клонировать любой вид более одного экземпляра. Данная операция
графических объектов. Итак, в нашем имеет доступ к переменной, где хранится
редакторе армий каждый инструмент для уникальный экземпляр, и гарантирует
создания элемента армии - это экземпляр инициализацию неременной этим экземпляром
класса GraphicTool, инициализированный тем перед возвратом ее клиенту. При таком
или иным прототипом. Любой экземпляр подходе можно не сомневаться, что одиночка
GraphicTool будет создавать армейский будет создан и инициализирован перед
объект, клонируя его прототип и добавляя первым использованием. порождение
клон в армейский строй. подклассов Singleton. Основной вопрос не
26Прототип [ Prototype ] Проблематика: столько в том, как определить подкласс, а
27Прототип [ Prototype ] Применимость: в том, как сделать, чтобы клиенты могли
система не должна зависеть от того, как в использовать его единственный экземпляр.
ней создаются, компонуются и По существу, переменная, ссылающаяся на
представляются продукты; инициализируемые экземпляр одиночки, должна
классы определяются во время выполнения, инициализироваться вместе с экземпляром
например с помощью динамической загрузки; подкласса. Простейший способ добиться
для того чтобы избежать построения этого - определить одиночку, которого
иерархий классов или фабрик, параллельных нужно применять в операции Instance класса
иерархии классов продуктов; экземпляры Singleton.
класса могут находиться в одном из не 54Обсуждение порождающих паттернов
очень большого числа различных состояний. Задача: параметризация системы классами
Может оказаться удобнее установить объектов. Первый способ: порождение
соответствующее число прототипов и подклассов от класса, создающего объекты.
клонировать их, а не инициализировать Это, по сути, фабричный метод. Недостаток
каждый раз класс вручную в подходящем – требуется порождать новый подкласс
состоянии. только для того, чтобы сменить класс
28Прототип [ Prototype ] Проблематика: продукта. Второй способ: композиция
29Участники: Prototype (Graphic) - объектов. Определяется объект, которому
Прототип: - объявляет интерфейс для известно о классах объектах-продуктах и
клонирования самого себя; этот объект делается параметром системы.
СonсretePrototype (Army- армия, Hero - Это основная идея трех паттернов:
герой) - конкретный прототип: - реализует абстрактная фабрика, строитель и прототип.
Типовые решения проектирования.ppt
http://900igr.net/kartinka/cherchenie/tipovye-reshenija-proektirovanija-211533.html
cсылка на страницу

Типовые решения проектирования

другие презентации на тему «Типовые решения проектирования»

«Проектирование пресс-форм» - Механизм оформления поднутрения. Неподвижная часть. Стандартные элементы системы охлаждения. Выбор нормали на дереве категорий. Модель телефонной трубки в SolidWorks. Проектирование пресс-форм с использованием системы Технорма. Система съема. Фильтр типоразмеров. Выбор типоразмера нормали. Центрирующие фланцы фиксируют пресс-форму на литьевой машине.

«Социальное проектирование» - Разработка социального проекта I раздел. Определения уровня развития проектной компетенции в период с 2007 по 2010 год. II раздел Реализация разработанного проекта силами инициативной группы школьников. Формулировка социальной проблемы, актуальной в данном местном сообществе. Информирование общественности о результатах реализации проекта.

«3d проектирование» - Выполнение построений с использованием параметрических объектов (примитивов). 3D проектирование. Задачи курса: предоставить студентам необходимые знания и навыки для самостоятельного использования программы. Композиция трехмерных сцен (создание освещения, расстановка камер). Навыки использования программы трехмерного проектирования.

«Проектирование баз данных» - Плохо нормализованная таблица. Проектирование баз данных. Задание структуры базы данных. Нормализованная база данных. Проектирование. Создание структуры базы данных и заполнение. Таблица может быть: Хорошо нормализованной Плохо нормализованной. Этапы создания базы данных. Работа с сохраненной базой данных.

«Дипломное проектирование» - Проходил преддипломную практику. Требования к реализационной части проекта не должны быть ни занижены, ни завышены. В 2008 г. был проведен Первый Всероссийский Конкурс дипломных проектов с использованием ПП «1С». На все практики - 57 зачетных единицах (2052). Иногда, но редко, УЗ оплачивает работу руководителей преддипломной практики.

«Основы инженерной графики» - Наибольшее значение и применение. Изображения различных предметов и объектов не являются самоцелью. Из истории инженерной графики. Добряков А. И.. В архиве сохранился чертеж весельного шлюпа. Курдюмов В.И.. Древнейшие чертежи относятся к XYI веку. Рынин Н. А.. Чертежные инструменты и принадлежности.

Графика

7 презентаций о графике
Урок

Черчение

7 тем
Картинки
900igr.net > Презентации по черчению > Графика > Типовые решения проектирования