55. Grasp: принцип Creator.

Проблема. Кто должен отвечать за создание нового экземпляра некоторого класса? Создание объектов в объектно-ориентированной системе является одним из наиболее стандартных видов деятельности. Следовательно, при назначении обязанностей, связанных с созданием объектов, полезно руководствоваться некоторым основным принципом. Правильно распределив

обязанности при проектировании, можно создать слабо связанные независимые компоненты с возможностью их дальнейшего использования, упростить их, а также обеспечить инкапсуляцию данных и их повторное использование.

Решение. Назначить классу В обязанность создавать экземпляры класса А если выполняется одно из следующих условий:

• класс В агрегирует (aggregate) или содержит (contains) объекты А;

• класс В записывает (records) или активно использует (closely uses) экземпляры объектов А;

• класс В обладает данными инициализации (has the initializing data), которые будут передаваться объектам А при их создании (т. е. при создании объектов А класс В является информационным экспертом).

Класс В называется создателем (creator) объектов А.

Если выполняется несколько из этих условий, то лучше использовать

класс В, агрегирующий или содержащий класс А.

Пример. Кто должен отвечать за создание нового экземпляра объекта SalesLineItem? В соответствии с шаблоном Creator, необходимо найти класс, агрегирующий, содержащий и т.д. экземпляры объектов SalesLineItem. Рассмотрим фрагмент модели предметной области, представленной на рис. 3.

Поскольку объект Sale содержит (фактически — агрегирует) несколько объектов SalesLineItem, согласно шаблону Creator, он является хорошим кандидатом для выполнения обязанности, связанной с созданием экземпляров объектов SalesLineItem. Такой подход приводит к необходимости разработки взаимодействия объектов, показанного на рис. 8.

Рис. 8. Создание экземпляра объекта SalesLineItem

При таком распределении обязанностей требуется, чтобы в объекте Sale был определен метод makeLineItem.

Назначение. Шаблон Creator определяет способ распределения обязанностей, связанный с процессом создания объектов. В объектно-ориентированных системах эта задача является одной из наиболее распространенных. Основным назначением шаблона Creator является выявление объекта-создателя, который при возникновении любого события должен быть связан со всеми созданными им объектами. При таком подходе обеспечивается низкая степень связанности. Целое агрегирует свои части, контейнер хранит свое содержимое, регистратор ведет учет. Все эти взаимосвязи являются очень распространенными способами взаимодействия классов в диаграмма классов. В шаблоне Creator определяется, что внешний контейнер или класс-регистратор это хорошие кандидаты на выполнение обязанностей, связанных с созданием сущностей, которые они будут содержать или регистрировать. Конечно, это утверждение является лишь рекомендацией.

В некоторых случаях в качестве создателя выбирается класс, который содержит данные инициализации, передаваемые объекту во время его создания. На самом деле это пример использования шаблона Information Expert. В процессе создания инициализирующие данные передаются с помощью метода инициализации некоторого вида, такого как конструктор языка Java с параметрами. Например, предположим что при создании экземпляр объекта Payment нужно инициализировать с использованием общей суммы, содержащейся в объекте Sale. Поскольку объекту Sale эта сумма известна, он является кандидатом на выполнение обязанности, связанной с созданием экземпляра объекта Payment.

Когда не следует применять шаблон.

Зачастую создание экземпляра — это достаточно сложная операция, выполняемая при реализации некоторого условия на основе каких-либо внешних свойств. В этом случае предпочтительнее использовать шаблон Factory (Фабрика) и делегировать обязанность создания экземпляров вспомогательному классу.

Преимущества

• Поддерживается шаблон Low Coupling, способствующий снижению затрат на сопровождение и обеспечивающий возможность повторного использования созданных компонентов в дальнейшем.

• Применение шаблона Creator не повышает степени связанности, поскольку созданный класс, как правило, оказывается видимым для класса-создателя посредством имеющихся ассоциаций.