Образец «Information Expert»

Проблема:

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

Решение:

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

Пример:

При выполнении подчиненного потока событий «Обновить график» варианта использования «Зарегистрироваться на курсы» (рис. 4.9) студент-пользователь должен получить доступ к своему графику прежде, чем изменить его. Согласно образцу «Information Expert», нужно определить, объект какого класса содержит инфор­мацию, необходимую для доступа к графику. На эту роль информа­ционного эксперта, очевидно, претендует объект класса-сущности Student, поскольку график принадлежит именно ему. Поэтому со­общение 3 «get schedule(forSemester)» должно быть направлено от контроллера объекту класса Student. После того, как студент полу­чит график и внесет в него необходимые изменения, они должны быть зафиксированы в объекте Schedule. В данном случае уже сам объект Schedule будет играть роль информационного эксперта, поскольку он непосредственно доступен контроллеру, и сообще­ние 10 «update with new selections» будет направлено именно ему.

Следствия:

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

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

В некоторых ситуациях применение образца Information Expert нежелательно. Например, в системе регистрации нужно определить, какой объект должен отвечать за сохранение инфор­мации об учебных курсах в базе данных. Информация, подлежа­щая сохранению, «известна» объекту Course, а значит, согласно образцу Information Expert, на класс Course следует возложить обязанность по сохранению. Логическим следствием такого рас­суждения является вывод о том, что каждый объект должен отве­чать за сохранение себя в базе данных. Однако при этом возника­ет проблема перегруженности класса лишними обязанностями, поскольку класс Course должен содержать методы обращения к базе данных, т.е. должен быть связан с вызовом операторов язы­ка SQL или сервисов JDBC (Java Database Connectivity). Тогда этот класс не будет относиться к предметной области и модели­ровать учебные курсы. Кроме того, подобные действия будут дублироваться во многих других классах, информация которых под­лежит постоянному хранению.

Все эти проблемы приводят к нарушению основного архитек­турного принципа проектирования с разделением основных функций системы на уровни, отраженного в образце «Уровни». Разнородные функции не должны реализовываться в одном и том же компоненте. С этой точки зрения класс Course не должен отвечать за сохранение информации в базе данных.

Основное достоинство образца Information Expert - поддерж­ка инкапсуляции. Для выполнения требуемых задач объекты ис­пользуют собственные данные. Необходимое поведение системы обеспечивается несколькими классами, содержащими требуемую информацию. Это приводит к определениям классов, которые гораздо проще понимать и поддерживать.