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

 1. UML-диаграмма для паттерна Абстрактная фабрика

---

176
«Молодой учёный» . № 4 (138)  . Январь 2017 г.
Информатика
voice (). То нам нужно создать класс-создатель (Creator), 
у которого должны быть наследники: создатель кошек и 
собак (ConcreteCreator). Тогда клиент будет обращаться к 
классу Creator, а тот уже зависит от Product, и на уровне 
Creator мы определяем кого будет создавать, кошек или 
собак.
Рис.
 2. UML-диаграмма паттерна «Фабричный метод»
Данный паттерн используется, когда:
— классу заранее неизвестно, объекты каких под-
классов ему нужно создавать;
— класс спроектирован так, чтобы объекты, которые 
он создает, специфицировались подклассами;
— класс делегирует свои обязанности одному из не-
скольких вспомогательных подклассов, и планируется ло-
кализовать значение о том, какой класс принимает эти 
обязанности на себя.
Если используется «Абстрактная фабрика», то этот 
паттерн является ядром системы, либо ядром значительно 
части системы, а «Фабричный метод», как правило, ис-
пользуется для решения одного маленького кусочка. И 
может использоваться по всей системе во многих её ча-
стях.
Однако, в таком каноничном виде паттерн встреча-
ется уже редко. Поскольку класс Creator должен содер-
жать хотя бы один метод, принимающий что-то на вход 
(аргумент или строку) и определяющий какой класс-по-
томок (ConcreteCreator) создавать, проще не создавать 
класс-потомок, а напрямую инстанцировать кошек или 
собак (ConcreteProduct) из данного метода.
Следующая доработка данного паттерна заключается в 
отказе от класса Creator. Поскольку, раз он только и де-
лает, что создает объекты другого интерфейса, то согласно 
шаблону «Information expert» просто перенесем его метод 
create () в интерфейс «Animal» (Product), который станет 
абстрактным классом со статическим методом create (), 
принимающим тип того, что необходимо создать, и соз-
дает либо кошку, либо собаку (ConcreteProduct). С точки 
зрения логики это ужас, поскольку возникает цикличе-
ская зависимость. Однако, если рассматривать все эти 
три класса как единый объект, а именно так их и нужно 
рассматривать, то получается эффективно. Поскольку 
клиенту возвращается тип Animal, а кошек и собак он 
«ни разу не видел». Вокруг этого паттерна построен весь 
JDBC: Connection, getConnection () и т. д.
На сегодняшний день «Фабричный метод» де-факто 
канонический способ создания полиморфных классов. 
Его преимущество в избавлении проектировщика от не-
обходимости встраивать в код зависящие от приложения 
классы.
Основной недостаток заключается в дополнительном 
уровне подклассов.
Литература:
1. Гамма, Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Пат-
терны проектирования. СПб.: Питер, 2001.
2. Ларман, К. Применение UML и шаблонов проектирования. Вильямс, 2002.
3. DeanLeffingwell, Don Widrig. Managing Software Requirements. Addison-Wesley, 2000.
4. Rational Unified Process. Versions 2001–2003. Rational Software Corporation. http://www. rational. com/
5. Мартин Фаулер — Архитектура корпоративных программных — М.: «Вильямс», 2007. — с. 544.

---