11.3.3 Шаги проектирования

Рассмотрим проектирование отдельного класса. Обычно это не лучший

метод. Понятия не существуют изолированно, наоборот, понятие

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

существует изолированно, а определяется совместно с множеством

связанных между собой классов. Это множество часто называют

библиотекой классов или компонентом. Иногда все классы компонента

образуют единую иерархию, иногда это не так (см. $$12.3).

Множество классов компонента бывают объединены некоторым логическим

условием, иногда это - общий стиль программирования или описания,

иногда - предоставляемый сервис. Компонент является единицей

проектирования, документации, права собственности и,

часто, повторного использования.

Это не означает, что если вы используете один класс компонента, то

должны разбираться во всех и уметь применять все классы компонента или

должны подгружать к вашей программе модули всех классов компонента. В

точности наоборот, обычно стремятся обеспечить, чтобы использование

класса вело к минимуму накладных расходов: как машинных ресурсов,

так и человеческих усилий. Но для использования любого класса

компонента нужно понимать логическое условие, которое его

определяет (можно надеяться, что оно предельно ясно изложено в

документации), понимать соглашения и стиль, примененный в процессе

проектирования и описания компонента, и доступный сервис (если он

есть).

Итак, перейдем к способам проектирования компонента. Поскольку

часто это непростая задача, имеет смысл разбить ее на шаги и,

сконцентрировавшись на подзадачах, дать полное и последовательное

описание. Обычно нет единственно правильного способа разбиения.

Тем не менее, ниже приводится описание последовательности шагов,

которая пригодилась в нескольких случаях:

[1] Определить понятие / класс и установить основные связи

между ними.

[2] Уточнить определения классов, указав набор операций для

каждого.

[a] Провести классификацию операций. В частности уточнить

необходимость построения, копирования и уничтожения.

[b] Убедиться в минимальности, полноте и удобстве.

[3] Уточнить определения классов, указав их зависимость от

других классов.

[a] Наследование.

[b] Использование зависимостей.

[4] Определить интерфейсы классов.

[a] Поделить функции на общие и защищенные.

[b] Определить точный тип операций класса.

Отметим, что это шаги итеративного процесса. Обычно для получения

проекта, который можно уверенно использовать для первичной реализации

или повторной реализации, нужно несколько раз проделать

последовательность шагов. Одним из преимуществ глубокого анализа и

предложенной здесь абстракции данных оказывается относительная

легкость, с которой можно перестроить взаимоотношения классов

даже после программирования каждого класса. Хотя это никогда не

бывает просто.

Далее следует приступить к реализации классов, а затем

вернуться, чтобы оценить проект, исходя из опыта реализации.

Рассмотрим эти шаги в отдельности.

11.3.3.1 Шаг 1: определение классов

Определите понятия/классы и установите основные связи между ними.

Главное в хорошем проекте - прямо отразить какое-либо понятие

"реальности", т.е. уловить понятие из области приложения классов,

представить взаимосвязь между классами строго определенным способом,

например, с помощью наследования, и повторить эти действия на

разных уровнях абстракции. Но как мы можем уловить эти понятия?

Как на практике решить, какие нам нужны классы?

Лучше поискать ответ в самой области приложения, чем рыться

в программистском хранилище абстракций и понятий. Обратитесь к тому,

кто стал экспертом по работе в некогда сделанной системе, а также

к тому, кто стал критиком системы, пришедшей ей на смену. Запомните

выражения того и другого.

Часто говорят, что существительные играют роль классов и объектов,

используемых в программе, это действительно так. Но это только начало.

Далее, глаголы могут представлять операции над объектами или

обычные (глобальные) функции, вырабатывающие новые значения, исходя

из своих параметров, или даже классы. В качестве примера

можно рассматривать функциональные объекты, описанные в $$10.4.2.

Такие глаголы, как "повторить" или "совершить" (commit) могут быть

представлены итеративным объектом или объектом, представляющим

операцию выполнения программы в базах данных.

Даже прилагательные можно успешно

представлять с помощью классов, например, такие, как "хранимый",

"параллельный", "регистровый", "ограниченный". Это могут быть классы,

которые помогут разработчику или программисту, задав виртуальные

базовые классы, специфицировать и выбрать нужные свойства для

классов, проектируемых позднее.

Лучшее средство для поиска этих понятий / классов - грифельная

доска, а лучший метод первого уточнения - это беседа со специалистами

в области приложения или просто с друзьями. Обсуждение необходимо,

чтобы создать начальный жизнеспособный словарь терминов и понятийную

структуру. Мало кто может сделать это в одиночку. Обратитесь к [1],

чтобы узнать о методах подобных уточнений.

Не все классы соответствуют понятиям из области приложения.

Некоторые могут представлять ресурсы системы или абстракции

периода реализации (см. $$12.2.1).

Взаимоотношения, о которых мы говорим, естественно устанавливаются

в области приложения или (в случае повторных проходов по шагам

проектирования) возникают из последующей работы над структурой классов.

Они отражают наше понимание основ области приложения. Часто они

являются классификацией основных понятий. Пример такого отношения:

машина с выдвижной лестницей есть грузовик, есть пожарная машина,

есть движущееся средство.

В $$11.3.3.2 и $$11.3.3.5 предлагается некоторая точка зрения на

классы и иерархию классов, если необходимо улучшить их структуру.