Книга: Технологии программирования
8.9.4. Уточнение классов с точным определением их зависимостей от других классов. Продолжение учебного примера
8.9.4. Уточнение классов с точным определением их зависимостей от других классов. Продолжение учебного примера
Продолжим разработку программы РКП. На следующих этапах уточняется описание объектов. Сначала формализуются способы взаимодействия.
Следует определить, как будет реализован каждый из объектов. Объект, характеризуемый только поведением (не имеющий внутреннего состояния — внутренних данных), может быть оформлен в виде функции. Например, объект, заменяющий в строке все прописные буквы на строчные, лучше представить в виде функции. Объекты со многими функциями лучше реализовать в виде классов. Каждой обязанности, перечисленной на CRC-карточке, присваивается имя. Эти имена станут затем названиями функций или процедур. Вместе с именами определяются типы аргументов, передаваемых функциям и процедурам. Затем описывается вся информация, содержащаяся внутри класса объекта. Если объекту требуются некоторые данные для выполнения конкретного задания, их источник (аргумент функции, глобальная или внутренняя переменная) должен быть описан явно.
Как только для всех действий выбраны имена, CRC-карточка для каждого объекта переписывается заново с указанием имен функций и списка формальных параметров (рис. 8.11). Теперь CRC-карточка в себе отражает всю информацию для записи описания класса, порождающего объект, отображенный на этой карточке.
Идея классификации классов объектов программы через их поведение имеет чрезвычайное следствие. Программист знает, как использовать объект, разработанный другим программистом, и при этом ему нет необходимости знать, как он реализован. Пусть классы шести объектов РКП разрабатываются шестью программистами. Программист, разрабатывающий класс объекта Meal, должен обеспечить просмотр базы данных с рецептами и выбор отдельного рецепта при составлении блюда. Для этого объекта Meal просто вызывает функцию browse, привязанную к объекту RecipeDatebase. Функция browse возвращает отдельный рецепт Recipe из базы данных. Все это справедливо вне зависимости от того, как конкретно реализован внутри Recipe Database просмотр базы данных.
Рис. 8.11. Уточненная CRC-карточка
Вероятно, в реальном приложении будет много рецептов. Однако все они будут вести себя одинаково. Отличается лишь состояние: список ингредиентов и инструкций по приготовлению. На ранних стадиях разработки нас должно интересовать поведение, общее для всех рецептов. Детали, специфические для отдельного рецепта, не важны. Заметим, что поведение ассоциировано с классом, а не с индивидуальным представителем, т. е. все экземпляры класса воспринимают одни и те же команды и выполняют их сходным образом. С другой стороны, состояние является индивидуальным, и это видно на примере различных экземпляров класса Recipe. Все они могут выполнять одни и те же действия (редактирование, вывод на экран, печать), но используют различные данные.
Двумя важными понятиями при разработке программ является зацепление (cohesion) и связанность (coupling). Связанность — это мера того, насколько отдельный объект образует логически законченную, осмысленную единицу. Высокая связанность достигается объединением в одном объекте соотносящихся (в том или ином смысле) друг с другом функций. Наиболее часто функции оказываются связанными друг с другом при необходимости иметь доступ к общим данным. Именно это объединяет различные части объекта Recipe.
В частности, зацепление возникает, если один объект должен иметь доступ к данным (состоянию) другого объекта. Следует избегать подобных ситуаций. Возложите обязанность осуществлять доступ к данным на объект, который ими владеет. Например, за редактирование рецептов ответственность должна лежать на объекте RecipeDatabase, поскольку именно в нем впервые в этом возникает необходимость. Но тогда объект RecipeDatabase должен напрямую манипулировать состоянием отдельных рецептов (их внутренними данными: списком ингредиентов и инструкциями по приготовлению). Лучше избежать столь тесного сцепления, передав обязанность редактирования непосредственно рецепту.
С другой стороны, зацепление характеризует взаимосвязь между объектами программы. В общем случае желательно, как только можно, уменьшить степень зацепления, поскольку связи между объектами программы препятствуют их модификации и мешают дальнейшей разработке или повторному использованию в других программах.
- 8.9.1. RDD-технология проектирования на основе обязанностей
- 8.9.2. Начинаем с анализа функционирования. Учебный пример объектно-ориентированного проекта средней сложности
- 8.9.3. Динамическая модель системы
- 8.9.4. Уточнение классов с точным определением их зависимостей от других классов. Продолжение учебного примера
- 8.9.5. Совместное рассмотрение трех моделей
- Продолжение линии 1.0
- Удаление учебного узла
- Delphi. Учимся на примерах
- Вот уже в который раз при работе в сети появляется сообщение от других пользователей. Что это может быть?
- Как сделать движения мышью более точными?
- 9.7.4. Иерархии классов и абстрактные классы
- Место NeTAMS среди других считалок
- Бонусы с продолжением
- 8.8.5. Шаг 4. Задание интерфейсов классов
- Никаких других правил нет
- 9. Заработок для преподавателей иностранных языков и других дисциплин: создаем виртуальную школу
- У14.4 Наследование без классов