GRASP: принцип Information Expert.

Проблема. Каков наиболее общий принцип распределения обязанностей между объектами при объектно-ориентированном проектировании?

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

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

Решение. Назначить обязанность информационному эксперту — классу, у которого имеется информация, требуемая для выполнения обязанности.

Распределение обязанностей следует начинать с их четкой формулировки.

При использовании принципа Information Expert возникает ключевой вопрос: на основе какой модели нужно анализировать информацию — модели предметной области или проектирования? Модель предметной области иллюстрирует концептуальные классы из предметной области системы, а в модели проектирования показаны программные классы.

Ответ на этот вопрос сводится к следующему:

· если в модели проектирования имеются соответствующие классы, в первую очередь, следует использовать ее.

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

Пример. В приложении POS-системы NextGen некоторому классу необходимо знать общую сумму продажи. Сформулируем обязанность:

Какой класс должен отвечать за знание общей суммы продажи?

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

Следовательно, кандидатуру на роль информационного эксперта следует искать в модели предметной области. Вероятно, на эту роль подойдет концептуальный класс Sale. Тогда в модель проектирования нужно добавить соответствующий программный класс под именем Sale и присвоить ему обязанность вычисления общей стоимости, реализуемую с помощью вызова метода getTotal. При таком подходе сокращается разрыв между организацией программных объектов и соответствующих им понятий из предметной области.

Чтобы рассмотреть этот пример подробнее, обратимся к фрагменту модели предметной области (рис. 3).

Рис. 3. Фрагмент предметной области: классы Sale, SalesLineItem, ProductDescription

Какая информация требуется для вычисления общей суммы? Необходимо узнать  стоимость всех проданных товаров SalesLineltem и просуммировать эти промежуточные суммы. Такой информацией обладает лишь экземпляр объекта Sale. Следовательно, с точки зрения шаблона Information Expert объект Sale подходит для выполнения этой обязанности, т.е. является информационным экспертом.

Подобные вопросы распределения обязанностей зачастую возникают при создании диаграмм взаимодействий. Принятые решения иллюстрируются на фрагменте диаграммы взаимодействий, представленном на рис. рис. 4.

Рис. 4. Вычисление общей стоимости продажи

Однако на данном этапе выполнена не вся работа. Какая информация требуется для вычисления промежуточной суммы элементов продажи? Необходимы значения атрибутов SalesLineltem.quantity и SalesLineltem.price. Объекту SalesLineltem известно количество товара и известен связанный с ним объект roductDescription. Следовательно, в соответствии с шаблоном Expert, промежуточную сумму должен вычислять объект SalesLineltem. Другими словами, этот объект является информационным экспертом.

В терминах диаграмм взаимодействий это означает, что объект Sale должен передать сообщения getSubtotal каждому объекту SalesLineltem, а затем просуммировать полученные результаты. Этот процесс проиллюстрирован на рис. 5.

Рис. 5. Вычисление общей стоимости продажи (продолжение)

Для выполнения обязанности, связанной со знанием и предоставлением промежуточной суммы, объекту SalesLineltem должна быть известна стоимость товара.

В данном случае в качестве информационного эксперта будет выступать объект ProductDescription. Результаты проектирования представлены на рис. 6.

Рис. 6. Вычисление общей стоимости продажи (окончание)

Распределение обязанностей «знать и предоставлять общую сумму продажи» между классами системы представлено на рис. 7.

Рис. 7. Распределение обязанностей по знанию и предоставлению общей суммы продажи

Рассмотрение и распределение обязанностей выполнялись в процессе создания диаграмм взаимодействия. Затем полученные результаты отображались на диаграммах классов (в качестве методов классов).

При назначении обязанностей, согласно шаблону Information Expert, был применен следующий принцип: обязанности связываются с тем объектом, который имеет информацию, необходимую для их выполнения.

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

Следует обратить внимание на то, что для выполнения обязанности зачастую   требуется информация, распределенная между различными классами или объектами. Это предполагает, что должно существовать много «частичных» экспертов, взаимодействующих при выполнении общей задачи.

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

Применение шаблона Expert приводит к тому, что объекты выполняют операции точно так, как они выполняются сущностями реального мира.

Именно эти сущности и моделируют объекты. Питер Код называет это стратегией «Сделай сам» (“Do It Myself”). Например, в реальном мире без применения электромеханических устройств покупка не сможет сообщить о своей стоимости. Она представляет собой неодушевленное понятие. Каждый из покупателей вычисляет сумму покупки самостоятельно. Однако в мире объектно-ориентированного программного обеспечения все программные объекты являются живыми и одушевленными, поэтому могут выполнять обязанности и осуществлять действия. В основном они выполняют действия, связанные с известной им информацией. В объектно-ориентированном

проектировании этот принцип называется «оживлением» (animation).

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

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

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

Например, какой объект должен отвечать за сохранение информации о продажах в базе данных? Безусловно, большая часть подлежащей сохранению информации «известна» объекту Sale, а значит, согласно шаблону Expert, на этот класс следует возложить обязанность по сохранению. Логическим следствием такого рассуждения является вывод о том, что каждый объект должен отвечать за сохранение себя в базе данных.

Однако при этом возникают проблемы связывания, зацепления и

дублирования. В частности, класс Sale должен содержать методы обращения к базе данных, т.е. быть связан с языком SQL или службами JDBC (Java Database Connectivity). Тогда этот класс не будет относиться к логике приложения и моделировать «продажу». При этом расширяется круг его обязанностей и снижается зацепление. Этот класс должен быть связан с техническими службами баз данных других подсистем, в частности со службами JDBC, а не только с программными объектами уровня предметной области. Кроме того, вероятно, подобная логика будет дублироваться во

многих других классах, информация о которых подлежит постоянному

хранению.

Все эти проблемы приводят к нарушению основного архитектурного принципа — проектирования с разделением основных функций системы.

Логика приложения должна храниться в одном месте (на уровне программных объектов предметной области), а логика связи с базой данных — в другом (в отдельной подсистеме служб базы данных). Различные функции не должны реализовываться в одном и том же компоненте.

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

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

· Шаблон Expert поддерживает инкапсуляцию. Для выполнения требуемых задач объекты используют собственные данные. Подобную возможность обеспечивает также шаблон Low Coupling, применение которого приводит к созданию более надежных и легко поддерживаемых систем.

· Соответствующее поведение системы обеспечивается несколькими классами, содержащими требуемую информацию. Это приводит к определениям классов, которые гораздо проще понимать и поддерживать. Кроме того, поддерживается шаблон High Cohesion.

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.