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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

есть).

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

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

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

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

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

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

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

между ними.

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

каждого.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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