WikiDer > Ответственный дизайн

Responsibility-driven design

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

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

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

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

Обзор

Дизайн, основанный на ответственности, фокусируется на объектах как поведенческие абстракции которые характеризуются своими обязанностями. В 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]
  • Варианты стиля управления: существует три различных стиля управления. Однако это не точные определения, поскольку можно сказать, что стиль управления более централизован или делегирован, чем другой.

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

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

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

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

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

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

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

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

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

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

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

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

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

Никогда.

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

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

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

  1. ^ Вирфс-Брок, Ребекка; Вилкерсон, Брайан (1989). «Объектно-ориентированный дизайн: подход, ориентированный на ответственность». Уведомления ACM SIGPLAN. 24 (10): 74. Дои:10.1145/74878.74885.
  2. ^ Энтони Дж. Х. Саймонс; Моник Снук; Китти Хунг (1998). «Шаблоны проектирования как лакмусовая бумага для проверки эффективности объектно-ориентированных методов». Oois'98. С. 129–147. CiteSeerX 10.1.1.130.8713. Дои:10.1007/978-1-4471-0895-5_10. ISBN 978-1-85233-046-0.
  3. ^ Стивен Р. Хейнс; Исаак Г. Каунцилл; Фрэнк Э. Риттер (2004). «Разработка объяснений на основе ответственности для когнитивных моделей».
  4. ^ Вирфс-Брок, Ребекка; Маккин, Алан (2003). Дизайн объекта: роли, обязанности и сотрудничество. Индианаполис, ИН: Аддисон-Уэсли. ISBN 978-0201379433.
  5. ^ а б c d е Вирфс-Брок и Маккин, 2002 г., стр. 3
  6. ^ Вирфс-Брок и Маккин, 2002 г., стр.58
  7. ^ а б c Вирфс-Брок и Маккин, 2002 г., стр.61
  8. ^ а б Вирфс-Брок и Маккин, 2002 г., стр.72
  9. ^ а б Вирфс-Брок и Маккин, 2002 г., стр.17
  10. ^ а б Вирфс-Брок и Маккин, 2002 г., стр. 126
  11. ^ а б c Вирфс-Брок и Маккин, 2002 г., стр.168
  12. ^ Вирфс-Брок и Маккин, 2002 г., стр. 340
  13. ^ а б c d е Вирфс-Брок и Маккин, 2002 г., стр.4
  14. ^ а б c d е ж Вирфс-Брок и Маккин, 2002 г., стр.93
  15. ^ а б c Вирфс-Брок и Маккин, 2002 г., стр.165
  16. ^ Вирфс-Брок и Маккин, 2002 г., стр.164
  17. ^ а б Эрик, Аришолм; Даг И.К., Шоберг (2004). «Оценка влияния делегированного или централизованного стиля управления на ремонтопригодность объектно-ориентированного программного обеспечения». IEEE Transactions по разработке программного обеспечения. 30 (8): 521–534. Дои:10.1109 / TSE.2004.43.
  18. ^ Вирфс-Брок и Маккин, 2002 г., стр. 196
  19. ^ Вирфс-Брок и Маккин, 2002 г., стр.197
  20. ^ Вирфс-Брок и Маккин, 2002 г., стр.213
  21. ^ Вирфс-Брок и Маккин, 2002 г., стр.30

Список используемой литературы