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

Question

В этом тексте я читаю

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

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

Answer 1

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

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".

Answer 2

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

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

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

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

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

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

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