Дизайн, ориентированный на ответственность
Метод проектирования в объектно-ориентированном программировании

Responsibility-driven design — это метод проектирования в объектно-ориентированном программировании , который улучшает инкапсуляцию с помощью клиент-серверной модели . Он фокусируется на контракте , рассматривая действия, за которые отвечает объект , и информацию, которой объект делится. Он был предложен Ребеккой Вирфс-Брок и Брайаном Вилкерсоном.

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

В модели клиент-сервер, на которую они ссылаются, и клиент, и сервер являются классами или экземплярами классов. В любой конкретный момент времени либо клиент, либо сервер представляют объект. Обе стороны обязуются выполнять контракт и обмениваться информацией, придерживаясь его. Клиент может делать только запросы, указанные в контракте, а сервер должен отвечать на эти запросы. [1] Таким образом, проектирование, основанное на ответственности, пытается избежать работы с деталями, такими как способ выполнения запросов, вместо этого указывая только цель определенного запроса. Преимущество заключается в повышенной инкапсуляции , поскольку спецификация точного способа выполнения запроса является частной для сервера.

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

Обзор

Проектирование, основанное на ответственности, фокусируется на объектах как поведенческих абстракциях, которые характеризуются своими обязанностями. Для создания этих поведенческих абстракций используется метод моделирования CRC-карт . Остальная часть структуры объекта, включая атрибуты данных, назначается позже, по мере необходимости. [2] Это заставляет проект следовать иерархии типов для наследования, что улучшает инкапсуляцию и упрощает идентификацию абстрактных классов . Он также может группировать классы вместе на основе их клиентов, что считается уникальной способностью.

Хороший объектно-ориентированный дизайн подразумевает раннее внимание к поведению для реализации возможностей, соответствующих заявленным требованиям, и позднее связывание деталей реализации с требованиями. Этот подход особенно помогает децентрализовать управление и распределить поведение системы, что может помочь управлять сложностями высокофункциональных больших или распределенных систем. Аналогично, он может помочь проектировать и поддерживать средства объяснения для когнитивных моделей , интеллектуальных агентов и других систем, основанных на знаниях . [3]

Строительные блоки

В своей книге «Проектирование объектов: роли, обязанности и сотрудничество » [4] авторы описывают следующие строительные блоки, из которых состоит проектирование, основанное на ответственности.

  • Приложение: Программное приложение — это набор взаимодействующих объектов. [5]
  • Кандидаты: Кандидаты или объекты-кандидаты — это ключевые концепции в форме объектов, описанных на карточках CRC. Они служат первоначальными изобретениями в процессе проектирования объектов. [6]
  • Сотрудничества: Сотрудничество определяется как взаимодействие объектов или ролей (или того и другого). [5]
  • Карточки CRC: CRC означает Кандидаты, Обязанности, Коллабораторы. Это карточки, которые использовались в раннем дизайне для записи кандидатов. [7] Эти карточки разделены на нелинованную и линованную сторону.
    • Содержание линованной стороны: На этой стороне записывается имя кандидата, его обязанности и его соратники. [7]
    • Содержание нелинованной стороны: На этой стороне записывается имя кандидата, его цель в заявке, стереотипные роли и любая ценная информация, например, названия ролей в шаблонах, в которых он участвует. [7]
  • Горячие точки: Горячие точки — это точки в приложении, где происходят изменения. Они регистрируются с помощью карт горячих точек. [8]
  • Карточки горячих точек: Карточки горячих точек используются для записи вариаций с достаточной детализацией, чтобы вы могли различить важные различия. Подобно карточкам CRC, они также создаются из карточек . [8] Эти карточки состоят из:
    • Название горячей точки
    • Общее описание вариации
    • По крайней мере два конкретных примера, где встречается вариация

Объекты

Объекты описываются как вещи, которые имеют машиноподобное поведение, которое может быть подключено вместе для совместной работы. Эти объекты играют четко определенные роли и инкапсулируют заскриптованные ответы и информацию. [5]

  • Соседства объектов: Другой термин для подсистемы. [9] Это логическая группировка участников. [9]
  • Обязанности: Обязанность — это обязательство выполнить задачу или узнать информацию. [5] Они далее классифицируются в соответствии со сценарием использования.
    • Общественная ответственность: Общественная ответственность — это обязанности, которые объект предлагает в качестве услуг другим, а также информация, которую он предоставляет другим. [10]
    • Частная ответственность: Частная ответственность — это действия, которые объект предпринимает в поддержку общественных обязанностей. [10]
    • Подчиненные обязанности: Иногда большая или сложная обязанность делится на более мелкие, называемые подчиненными обязанностями. [11] Они далее классифицируются в зависимости от того, что они делают.
      • Подчиненные обязанности: они включают основные шаги в каждой подответственности. [11]
      • Последовательность обязанностей: они относятся к последовательности выполнения подчиненных обязанностей. [11]

Роли

Роль объекта относится к внешнему виду того, какую общую услугу предлагает объект. Это набор связанных обязанностей. [5] Он может быть реализован как класс или интерфейс. Интерфейс, однако, является предпочтительной реализацией, поскольку он увеличивает гибкость, скрывая конкретный класс, который в конечном итоге выполняет работу. [12]

Ролевые стереотипы: Ролевые стереотипы — это упрощенные роли, которые сопровождаются предопределенными обязанностями. [13] Существует несколько категорий.

  • Контроллер: Объект, реализующий эту роль, принимает решения и тесно управляет действиями других объектов. [13]
  • Координатор: эта роль заключается в реагировании на события путем делегирования задач другим. [13]
  • Держатель информации: Держатель информации знает и предоставляет информацию. [13]
    • Поставщик информации: Небольшой вариант держателя информации — поставщик информации, который играет более активную роль в управлении и поддержании информации. Это различие может быть использовано, если дизайнеру нужно получить больше конкретики. [14]
  • Интерфейс: эта роль преобразует информацию и запросы между различными частями приложения. [13] Она далее делится на более конкретные роли.
    • Внешний интерфейс: Внешний интерфейс взаимодействует с другими приложениями, а не со своим собственным. [14] Он в основном используется для инкапсуляции необъектно-ориентированных API и не слишком тесно взаимодействует. [15]
    • Внутренний интерфейс: также называется межсистемным интерфейсом. [14] Он действует как мост между соседними объектами. [15]
    • Пользовательский интерфейс: Пользовательский интерфейс взаимодействует с пользователями, реагируя на события, генерируемые в пользовательском интерфейсе, а затем передавая их более подходящим объектам. [14] [15] [16]
  • Поставщик услуг: эта роль заключается в выполнении работы и предоставлении вычислительных услуг. [14]
  • Структурировщик: эта роль поддерживает связи между объектами и информацию об этих связях. [14]

Стиль управления

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

  • Концепция контроля: обязанности и сотрудничество между классами. [17]
  • Центры управления: Важным аспектом разработки стиля управления является изобретение так называемых центров управления. Это места, где находятся объекты, ответственные за управление и координацию. [18]
  • Вариации стилей управления: Стиль управления существует в трех различных вариациях. Это не точные определения, поскольку можно сказать, что один стиль управления более централизован или делегирован, чем другой.

Централизованный стиль управления

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

Типы
  • Модель вызова-возврата: Управление объектами в приложении осуществляется иерархически. Управление начинается с корня и движется вниз. Используется в последовательной модели.
  • Модель менеджера: Управление объектами в приложении осуществляется только одним объектом. Обычно это реализуется в параллельных моделях. Это также может быть реализовано в последовательной модели с использованием оператора case .
Преимущества
  • Логика приложения находится в одном месте.
Недостатки
  • Логика управления может стать слишком сложной
  • Контролеры могут стать зависимыми от содержимого информации держателей
  • Объекты могут стать связанными косвенно через действия их контроллера.
  • Единственная интересная работа выполняется в контроллере.
Когда использовать

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

Стиль делегированного контроля

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

Типы[ссылка]
  • Модель вещания: событие транслируется всем объектам в приложении. Объект, который может обработать событие, может получить управление.
  • Модель, управляемая прерываниями: будет существовать обработчик прерываний для обработки прерывания и передачи его какому-либо объекту для его обработки.
Преимущества
  • Это легко понять.
  • Несмотря на наличие внешнего координатора, объекты можно сделать более интеллектуальными, чтобы они знали, что им следует делать, и могли повторно использоваться в других приложениях.
  • Делегирующие координаторы, как правило, знают о меньшем количестве объектов, чем доминирующие контроллеры.
  • Диалоги имеют более высокий уровень.
  • Его легко изменить, поскольку изменения обычно затрагивают меньшее количество объектов.
  • Проще распределить работу по проектированию между членами команды.
Недостатки
  • Слишком большое распределение ответственности может привести к появлению слабых объектов и слабого сотрудничества.
Когда использовать

Когда требуется делегировать работу более специализированным объектам.

Кластерный стиль управления

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

Распределенный стиль управления

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

Преимущества
  • Никто
Недостатки
  • Когда вы хотите узнать, как что-то работает, вам необходимо проследить последовательность запросов на услуги по многим объектам.
  • Не очень пригоден для повторного использования, так как ни один из объектов не вносит существенного вклада
Когда использовать

Никогда.

Предпочтительный стиль управления

После обширных результатов проведенных экспериментов только высшее руководство обладает необходимыми навыками для использования делегированного стиля управления и централизованного стиля управления, приносящего пользу программистам. Контекст о сотрудниках среднего звена не упоминается. [17]

Ссылки

  1. ^ Вирфс-Брок, Ребекка; Вилкерсон, Брайан (1989). «Объектно-ориентированное проектирование: подход, основанный на ответственности». ACM SIGPLAN Notices . 24 (10): 74. doi : 10.1145/74878.74885 .
  2. ^ Энтони Дж. Х. Саймонс; Моник Сноек; Китти Ханг (1998). «Шаблоны проектирования как лакмусовая бумажка для проверки прочности объектно-ориентированных методов». Oois'98 . С.  129–147 . CiteSeerX 10.1.1.130.8713 . doi :10.1007/978-1-4471-0895-5_10. ISBN  978-1-85233-046-0.
  3. ^ Стивен Р. Хейнс; Айзек Г. Каунсил; Фрэнк Э. Риттер (2004). «Разработка объяснений, основанных на ответственности, для когнитивных моделей».
  4. ^ Wirfs-Brock, Rebecca; McKean, Alan (2003). Object Design: Roles, Responsibilities, and Collaborations . Indianapolis, IN: Addison-Wesley. ISBN 978-0201379433.
  5. ^ abcde Wirfs-Brock & McKean 2002, стр. 3
  6. ^ Вирфс-Брок и МакКин 2002, стр. 58
  7. ^ abc Wirfs-Brock & McKean 2002, стр. 61
  8. ^ ab Wirfs-Brock & McKean 2002, стр. 72
  9. ^ ab Wirfs-Brock & McKean 2002, стр. 17
  10. ^ ab Wirfs-Brock & McKean 2002, стр. 126
  11. ^ abc Wirfs-Brock & McKean 2002, стр. 168
  12. ^ Вирфс-Брок и МакКин 2002, стр. 340
  13. ^ abcde Wirfs-Brock & McKean 2002, стр. 4
  14. ^ abcdef Wirfs-Brock & McKean 2002, стр. 93
  15. ^ abc Wirfs-Brock & McKean 2002, стр. 165
  16. ^ Вирфс-Брок и МакКин 2002, стр. 164
  17. ^ ab Эрик, Аришольм; Даг IK, Сьоберг (2004). «Оценка влияния делегированного и централизованного стиля управления на удобство обслуживания объектно-ориентированного программного обеспечения». IEEE Transactions on Software Engineering . 30 (8): 521– 534. doi :10.1109/TSE.2004.43. S2CID  6396127.
  18. ^ Вирфс-Брок и МакКин 2002, стр. 196
  19. ^ Вирфс-Брок и МакКин 2002, стр. 197
  20. ^ Вирфс-Брок и МакКин 2002, стр. 213
  21. ^ Вирфс-Брок и МакКин 2002, стр. 30

Библиография

  • Объектно-ориентированное проектирование: подход, основанный на ответственности. В трудах конференции по объектно-ориентированным системам программирования, языкам и приложениям (Новый Орлеан, Луизиана, США, 2–6 октября 1989 г.). OOPSLA '89. ACM Press, Нью-Йорк, штат Нью-Йорк, 71-75.
  • Wirfs-Brock, Rebecca; McKean, Alan (ноябрь 2002 г.). Объектный дизайн: роли, обязанности и сотрудничество . Addison Wesley . ISBN 978-0-201-37943-3.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Responsibility-driven_design&oldid=1268575108"