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

174
«Молодой учёный» . № 4 (138)  . Январь 2017 г.
Информатика
Литература:
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.
6. Алан Шаллоуей, Джеймс Р. Тротт. Шаблоны проектирования. Новый подход к объектно-ориентированному 
анализу и проектированию = Design Patterns Explained: A New Perspective on Object-Oriented Design. — М.: 
«Вильямс», 2002. — с. 288. —ISBN 0–201–71594–5.
7. Эрик Фримен, Элизабет Фримен. Паттерны проектирования = Head First Design Patterns. — СПб: Питер. — 
656 с. — ISBN 978–5–459–00435–9.
Шаблоны проектирования GoF. Порождающие шаблоны
Палиенко Алексей Николаевич, студент
Дальневосточный федеральный университет (г. Владивосток)
П
аттерны проектирования, впервые опубликованные в 
книге «Design Patterns — Elements of Reusable Ob-
ject-Oriented Software» Эрихом Гаммой и его товарищами, 
можно разделить на три группы: порождающие паттерны 
проектирования (Creational Patterns), структурные пат-
терны проектирования классов/объектов (Structural Pat-
terns) и паттерны проектирования поведения классов/
объектов (Behavioral Patterns). В это статье я рассмотрю 
основные порождающие шаблоны.
К порождающим паттернам относят следующие пат-
терны:
— Абстрактная фабрика (Abstract Factory, Factory) и 
др. название Инструментарий (Kit);
— Одиночка (Singleton);
— Прототип (Prototype);
— Строитель (Builder);
— Фабричный метод (Factory Method) или Вирту-
альный конструктор (Virtual Constructor).
Паттерн Абстрактная фабрика, или просто Фабрика, 
решает следующую проблему: создать семейство взаи-
мосвязанных объектов (не специфицируя их конкретных 
классов). Общий смысл следующий: у нас есть дерево объ-
ектов, и нам нужно собрать либо одно дерево либо другое. 
Деревья совершенно одинаковы, но делают разное.
Например, библиотека графических примитивов для 
одной операционной системы и библиотека графических 
примитивов для другой операционной системы. Делают 
они абсолютно одно и то же, но методы у них вызываются 
разные и ведут себя тоже различно. Однако нам не нужно 
создавать сразу и то, и другое. Если мы работаем под одной 
операционной системой, мы будем собирать одно дерево, 
если под другой, то другое. Но нам не хотелось бы поручать 
определение того, какой именно экземпляр из какого под-
множества деревьев создавать на этапе «runtime».
Решением является создание класса, в котором объ-
явлен интерфейс для создания конкретных классов.
Разберемся на примере. В нашей модели есть аб-
страктное окно, у которого есть две имплементации: окно 
для Windows и окно для Macintosh. А также различные 
аналогичные абстрактные объекты, например «Button», у 
которых есть две имплементации: для Windows и для Ma-
cintosh. Этап разработки проходит следующим образом: 
если у нас ОС Windows, то создаем объекты для Windows, 
если Macintosh, то для неё. Учитывая, что графических 
примитивов достаточно большое количество, такая схема 
работы не совсем удобна. Для упрощения предлагается 
создать некий класс Абстрактная фабрика.
Каждый из методов класса Абстрактная фабрика, на-
пример createProductA () возвращает просто AbstractPro-
ductA, то есть зависимость на наше абстрактное окно, а 
не его конкретную реализацию. Это абстрактная фабрика, 
она, на самом деле, ничего не производит. С точки зрения 
Java это просто интерфейс.
Но у Абстрактной фабрики есть конкретные имплемен-
тации: ConcreteFactory1 (WinFactory) и ConcreteFactory
2
(MacFactory), которые инстанцируют в коде конкретные 
объекты: для Mac»а ProductA2 (окно) и ProductB2 
(button), и аналогично для Windows.
В результате в бизнес-коде вызывается Абстрактный 
интерфейс (AbstractFactory), предварительно где-то в 
одном месте мы должны сказать, что используется либо 1 
либо 2 имплементация. И потом весь код работает через 
абстрактный интерфейс с конкретными классами, на-
пример ProductB2 и ProductA2. Поэтому наш бизнес-код 
может ничего не знать про конкретные имплементации, 
они защиты внутри.
Например, бизнес-логику мы, разумеется, кладем в 
клиентский (Client) код. Сюда же кладем все интерфейсы: 

---