Issn 2072-0297 Молодой учёный Международный научный журнал Выходит еженедельно №4 (138) / 2017 р е д а к ц и о н н а я к о л л е г и я : Главный редактор

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) и нам нужно 
заставить их подавать голос, вызывая, например, метод 
Рис.