моделирование на основе ответственности в сравнении с причинами изменения класса - PullRequest
Новая
       155

моделирование на основе ответственности в сравнении с причинами изменения класса

1 голос
/ 21 октября 2009

В этот текст, который я прочитал

Будьте внимательны к компоненту, который просто прославленная ответственность. компонент должен захватывать абстракция, которая имеет цель в система. Может случиться так, что появляется в один момент как значимый компонент действительно только один ответственность оставлена ​​сама по себе. Тот ответственность может быть возложена на компонент.

Это смущает меня. Если у класса должна быть только одна причина для изменения, кажется, что он должен иметь одну ответственность. Но теперь, кажется, я принимаю это слишком узко. Может ли как-то дать объяснение ответственности и причины изменения в контексте моделирования ответственности? Может ли класс иметь более двух обязанностей и при этом иметь одну причину для изменения (или наоборот)?

Ответы [ 2 ]

3 голосов
/ 21 октября 2009

Читать о моделировании (или дизайне) класса-ответственности-сотрудничества

http://www.agilemodeling.com/artifacts/crcModel.htm

http://alistair.cockburn.us/Using+CRC+cards

http://users.csc.calpoly.edu/~jdalbey/SWE/CaseStudies/ATMSim/CRCmodel.html

http://c2.com/doc/oopsla89/paper.html

У класса может быть несколько обязанностей. Он всегда представляет одну «вещь».

Правило "одна причина для изменения" не распространяется на обязанности. Период.

Правило «одна причина для изменения» должно использоваться следующим образом.

  1. Это не означает «1». Это означает «как можно меньше».

  2. Применяется к «интерфейсу», «базовой абстракции» или «концепции» для класса. Класс должен содержать несколько понятий. Когда основная концепция меняется, класс меняется.

  3. Многие простые вещи лучше, чем несколько сложных. Проще рекомбинировать и модифицировать простые вещи.

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

  5. Трудно определить «простой», но «одна концепция» близка. «Одна вещь, которую нужно изменить» также является полезным тестом для «простоты».

  6. Наконец, «одна причина для изменения» буквально не означает «1».

2 голосов
/ 21 мая 2010

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

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

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

Но означает ли это, что в системе должны быть два компонента: «инициировать новое письмо» и «ответить на электронное письмо»? Нет. Общий компонент "составить электронную почту" сможет удовлетворить оба требования.

Так что в этом случае компонент «составить письмо» отвечает за цели пользователя «инициировать новую почту» и «ответить на почту». Но его нужно будет изменить только в том случае, если изменится его основная концепция («как составляются электронные письма»).

Посмотрите еще раз внимательно на следующую фразу Кокберна: «Предполагается, что компонент захватывает абстракцию, имеющую цель в системе». Цель в системе (причина изменения) не совпадает с целью достижения цели (ответственности) пользователя.

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

...