Философия Java

         

Фаза 2: Как мы это построим?


В этой фазе вы должны перейти к дизайну, который описывает, как выглядят классы, и как они будут взаимодействовать. Лучшая техника для определения классов и взаимодействий - это карточки Сотрудничества-Классов-Взаимодействия (Class-Responsibility-Collaboration [CRC]). Часть ценности этого инструмента в том, что он низко-технический: вы начинаете с набора чистых карточек, размера 3х5, и вы пишете на них. Каждая карточка представляет один класс, а на карточке вы пишете:

  1. Имя класса. Важно, чтобы это имя содержало ядро того, что делает класс, так как это облегчает понимание.
  2. “Ответственность” класса: что класс должен делать. Обычно, это может добавляться к именам членов-функций (так как эти имена должны описываться в хорошем дизайне), но это не отменяет другие записи. Если вам необходим быстрый процесс, взгляните на проблему с точки зрения ленивого программиста: какие объекты должны магически возникнуть, чтобы решить вашу проблему?
  3. “Сотрудничество” классов: что другие классы делают при взаимодействии с ними? “Взаимодействие” - умышленно широкий термин; он должен означать конгломерат или просто то, что объект существует и будет выполнять обслуживание для объектов класса. Сотрудничество должно также рассматривать аудиторию этого класса. Например, если вы создаете класс Firecracker, кто будет наблюдать за ним: Chemist или Spectator? Создатель будет знать, что химикаты входят в конструкцию, а позже будет отвечать за цвет и освобожденную форму при взрыве.

Вы можете чувствовать, что карточки должны быть больше, вы захотите поместить на них всю информацию, но они специально маленькие, не только, чтобы сохранить ваши классы маленькими, но также и потому, чтобы вы не вдавались в детали слишком рано. Если вы не можете поместить все, что вам необходимо знать о классе на маленькую карточку, класс слишком сложный (либо вы слишком сильно детализируете, или вам надо создать более одного класса). Идеальный класс должен быть легко понимаем. Идея карточек CRC поможет вам перейти к первичному дизайну, так что вы получите большую картину, а затем очистите свой дизайн.


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

Прежде, чем я стал использовать CRC карточки, наиболее удовлетворительный опыт решения я имел, когда подходил к начальному дизайну, становясь перед командой — которая не строила прежде ООП проекты — и рисовал объекты на доске. Мы говорили о том, как объекты должны сообщаться с другими и стирали некоторые из них, заменяя их другими объектами. Действительно, я управлял всеми “CRC карточками” на доске. Команда (которая знала, что проект будет делать) реально создавала дизайн; они “овладели” дизайном раньше, чем я им это дал. Все, что я сделал - было руководство процессом путем постановки правильных вопросов, попыток приближений и получения обратной связи от команды, которая изменяла это приближение. Реальная красота процесса была в том, что команда училась тому, как делать объектно-ориентированный дизайн, не просматривая абстрактных примеров, но, работая над одним дизайном, наиболее интересным для них были они сами.

Когда вы придете к CRC карточкам, вы можете пожелать создать больший формат описания вашего дизайна, используя UML[13]. У вас нет необходимости использовать UML, но это может быть полезным, особенно если вы хотите поместить диаграмму на стену для каждого для обдумывания - это хорошая идея. Альтернативой UML является текстовое описание объектов и их взаимодействий, или, в зависимости от языка программирования, сам код [14].

UML также обеспечивает дополнительные комментарии к диаграммам для описания динамической модели вашей системы. Это полезно в ситуациях, при которых состояние переходов системы или подсистемы являются достаточно преобладающими, чтобы они имели собственную диаграмму (как в системах управления). Вам также может понадобиться описание структур данных для системы или подсистемы, в которых данные - преобладающий фактор (такие как базы данных).

Вы поймете, что завершили Фазу 2, когда получите описание объектов и их взаимодействий. Большинство из них - обычно некоторые прячутся в трещины и не дают о себе узнать до Фазы 3. Но это ничего. Все, с чем вы имели дело - это то, что вы исследовали все ваши объекты. Лучше их обнаружить раньше в процессе, но ООП обеспечивает достаточно структур, чтобы это не было плохо, если вы обнаружите их позже. Фактически, разработка объектов имеет склонность случаться на всех пяти стадиях в процессе разработки программы.


Содержание раздела