Ответственный дизайн
 |
Проектирование, основанное на ответственности, — это метод проектирования в объектно-ориентированном программировании , который улучшает инкапсуляцию за счет использования модели клиент-сервер . Он фокусируется на контракте , рассматривая действия, за которые отвечает объект , и информацию, которой объект делится. Его предложили Ребекка Вирфс-Брок и Брайан Вилкерсон.
Проектирование, основанное на ответственности, прямо противоположно проектированию, управляемому данными, которое способствует определению поведения класса вместе с данными, которые он содержит. Проектирование, управляемое данными, — это не то же самое, что программирование, управляемое данными , которое связано с использованием данных для определения потока управления , а не с проектированием классов.
В модели клиент-сервер, на которую они ссылаются, и клиент, и сервер являются классами или экземплярами классов. В любой конкретный момент времени либо клиент, либо сервер представляет объект. Обе стороны обязуются заключить договор и обмениваться информацией, придерживаясь его. Клиент может делать только запросы, указанные в контракте, а сервер должен отвечать на эти запросы. [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] Далее они классифицируются в зависимости от того, чем они занимаются.
Роли
[ редактировать ]Роль объекта относится к внешнему виду того, какую общую услугу предлагает объект. Это набор взаимосвязанных обязанностей. [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]
Ссылки
[ редактировать ]- ^ Вирфс-Брок, Ребекка; Вилкерсон, Брайан (1989). «Объектно-ориентированное проектирование: подход, основанный на ответственности» . Уведомления ACM SIGPLAN . 24 (10): 74. дои : 10.1145/74878.74885 .
- ^ Энтони Дж. Х. Саймонс; Моник Снук; Китти Хунг (1998). «Шаблоны проектирования как лакмусовая бумажка для проверки эффективности объектно-ориентированных методов» . Оойс'98 . стр. 129–147. CiteSeerX 10.1.1.130.8713 . дои : 10.1007/978-1-4471-0895-5_10 . ISBN 978-1-85233-046-0 .
- ^ Стивен Р. Хейнс; Исаак Г. Каунсил; Фрэнк Э. Риттер (2004). «Инженерия объяснений когнитивных моделей, основанная на ответственности» .
- ^ Вирфс-Брок, Ребекка; Маккин, Алан (2003). Объектный дизайн: роли, обязанности и сотрудничество . Индианаполис, Индиана: Аддисон-Уэсли. ISBN 978-0201379433 .
- ^ Перейти обратно: а б с д и Вирфс-Брок и Маккин, 2002 , стр. 3.
- ^ Wirfs-Brock & McKean 2002 , стр. 58.
- ^ Перейти обратно: а б с Вирфс-Брок и Маккин, 2002 , стр. 61.
- ^ Перейти обратно: а б Вирфс-Брок и Маккин, 2002 , стр. 72.
- ^ Перейти обратно: а б Вирфс-Брок и Маккин, 2002 , стр. 17.
- ^ Перейти обратно: а б Вирфс-Брок и Маккин, 2002 , стр. 126.
- ^ Перейти обратно: а б с Вирфс-Брок и Маккин, 2002 , стр. 168.
- ^ Wirfs-Brock & McKean 2002 , стр. 340.
- ^ Перейти обратно: а б с д и Вирфс-Брок и Маккин, 2002 , стр. 4.
- ^ Перейти обратно: а б с д и ж Вирфс-Брок и Маккин, 2002 , стр. 93.
- ^ Перейти обратно: а б с Вирфс-Брок и Маккин, 2002 , стр. 165.
- ^ Wirfs-Brock & McKean 2002 , стр. 164.
- ^ Перейти обратно: а б Эрик, Арисхольм; Даг И.К., Сьоберг (2004). «Оценка влияния делегированного и централизованного стиля управления на удобство сопровождения объектно-ориентированного программного обеспечения». Транзакции IEEE по разработке программного обеспечения . 30 (8): 521–534. дои : 10.1109/TSE.2004.43 . S2CID 6396127 .
- ^ Wirfs-Brock & McKean 2002 , стр. 196.
- ^ Wirfs-Brock & McKean 2002 , стр. 197.
- ^ Wirfs-Brock & McKean 2002 , стр. 213.
- ^ Wirfs-Brock & McKean 2002 , стр. 30.
Библиография
[ редактировать ]- Объектно-ориентированное проектирование: подход, основанный на ответственности . В материалах конференции по системам, языкам и приложениям объектно-ориентированного программирования (Новый Орлеан, Луизиана, США, 2–6 октября 1989 г.). УПСЛА '89. ACM Press, Нью-Йорк, Нью-Йорк, 71–75.
- Вирфс-Брок, Ребекка; Маккин, Алан (ноябрь 2002 г.). Объектный дизайн: роли, обязанности и сотрудничество . Эддисон Уэсли . ISBN 978-0-201-37943-3 .