175
“Young Scientist” . # 4 (138) . January 2017
Computer Science
AbstractFactory, AbstractProductA, AbstractProductB. А
реализации, например для Windows и для Mac»а, мы
можем положить в отдельный. jar файл.
Такое разделение позволяет проводить обновление,
например, графики: новый дизайн окна и кнопок, без не-
посредственного изменения клиентского кода, а только
заменяя в файле конфигурации связь интерфейса с кон-
кретным файлом реализации на новый файл имплемен-
тации. Система становится, во-первых, абсолютно легко
конфигурируемой, во-вторых, гибкой.
Преимущества паттерна «Абстрактная фабрика»:
— Изолирует конкретные классы. Поскольку «Аб-
страктная фабрика» инкапсулирует ответственность за
создание классов и сам процесс их создания, то она изоли-
рует клиента от деталей реализации класса;
— Упрощена замена «Абстрактной фабрики», по-
скольку она используется в приложении только один раз
при инстанцировании.
Недостатки:
— Интерфейс «Абстрактной фабрики фиксирует»
набор объектов, которые можно создать. Расширение
«Абстрактной фабрики» для изготовления новых объектов
часто затруднительно. Для примера представим пример
проекта, в котором много типов объектов (не 2 (Win,
Mac), а гораздо больше). Любое решение подразуме-
вает, что проект будет изменяться по какой-то оси. Осей
может быть очень много, может добавляться что одно, или
что-то другое, но ни одна система не растет одновременно
во всех направлениях. И у неё есть какое-то направление
расширения, например мы предположили, что будем рас-
ширяться в направлении поддержки новых операционных
систем. То есть будем добавлять еще одну фабрику (Con-
creteProductC) и реализации интерфейсов для С. Однако,
если у нас другая ось изменения и «поддержка двух опера-
ционных систем» прибито гвоздями и никогда изменяться
не будет, однако набор объектов ProductA1, ProductA2 и т.
д. постоянно меняется, то данный паттерн создаст множе-
ство неудобств. Потому что придётся не просто добавлять/
удалять конкретные продукты, но и изменять их список в
каждой конкретной фабрике. Это значительно усложнит
задачу. Поэтому для правильного выбора паттерна, не-
обходимо в самом начале понимать логику развития бу-
дущей системе: что будет изменяться, что будет добав-
ляться. То есть понимать будущую ось изменений.
Шаблон «Фабричный метод» (Factory Method) или
Виртуальный конструктор (Virtual Constructor) решает
следующую проблему:
необходимо определить интерфейс для создания объ-
екта, но оставить подклассам решение о том, какой класс
инстанцировать, то есть делегировать инстанцирование
подклассам.
Это означает, что в нашей системе нужно проинстан-
циировать либо один подкласс класса, либо другой. Если
у нас есть условный объект «Animal» (Product) и его на-
следники «Cat» и «Dog» (ConcreteProduct) и нам нужно
заставить их подавать голос, вызывая, например, метод
Рис.
Do'stlaringiz bilan baham: |