12.2 Классы

Основное положение объектно-ориентированного проектирования и

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

некоторых понятий реальности. Классы в программе представляют

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

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

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

реализации.

Мы рассмотрим структуру программы с точки зрения следующих

взаимоотношений между классами:

- отношения наследования,

- отношения принадлежности,

- отношения использования и

- запрограммированные отношения.

При рассмотрении этих отношений неявно предполагается, что их анализ

является узловым моментом в проекте системы. В $$12.4 исследуются

свойства, которые делают класс и его интерфейс полезными для

представления понятий. Вообще говоря, в идеале, зависимость класса

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

сам класс должен через интерфейс открывать лишь минимальный объем

информации для остального мира.

Подчеркнем, что класс в С++ является типом, поэтому сами классы

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

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

12.2.1 Что представляют классы?

По сути в системе бывают классы двух видов:

[1] классы, которые прямо отражают понятия области приложения,

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

описания своих задач и возможных решений;

и

[2] классы, которые являются продуктом самой реализации, т.е.

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

для описания способов реализации.

Некоторые из классов, являющихся продуктами реализации, могут

представлять и понятия реального мира. Например, программные и

аппаратные ресурсы системы являются хорошими кандидатами

на роль классов, представляющих область приложения. Это отражает

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

зрения, и то, что с одной является деталью реализации, с

другой может быть понятием области приложения. Хорошо

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

дают возможность рассматривать систему с логически

разных точек зрения. Приведем пример:

[1] классы, представляющие пользовательские понятия (например,

легковые машины и грузовики),

[2] классы, представляющие обобщения пользовательских понятий

(движущиеся средства),

[3] классы, представляющие аппаратные ресурсы (например, класс

управления памятью),

[4] классы, представляющие системные ресурсы (например,

выходные потоки),

[5] классы, используемые для реализации других классов (например,

списки, очереди, блокировщики) и

[6] встроенные типы данных и структуры управления.

В больших системах очень трудно сохранять логическое разделение

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

различными уровнями абстракции. В приведенном выше перечислении

представлены три уровня абстракции:

[1+2] представляет пользовательское отражение системы,

[3+4] представляет машину, на которой будет работать система,

[5+6] представляет низкоуровневое (со стороны языка программирования)

отражение реализации.

Чем больше система, тем большее число уровней абстракции необходимо

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

абстракции. Отметим, что таким уровням абстракции есть прямое

соответствие в природе и в различных построениях человеческого

интеллекта. Например, можно рассматривать дом как объект,

состоящий из

[1] атомов,

[2] молекул,

[3] досок и кирпичей,

[4] полов, потолков и стен;

[5] комнат.

Пока удается хранить раздельно представления этих уровней абстракции,

можно поддерживать целостное представление о доме. Однако, если

смешать их, возникнет бессмыслица. Например, предложение

"Мой дом состоит из нескольких тысяч фунтов углерода, некоторых

сложных полимеров, из 5000 кирпичей, двух ванных комнат и 13

потолков" - явно абсурдно. Из-за абстрактной природы

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

системе далеко не всегда воспринимают как бессмыслицу.

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

в класс вовсе не является простой механической операцией. Обычно

эта задача требует большой проницательности. Заметим, что сами

понятия области приложения являются абстракциями. Например, в

природе не существуют "налогоплательщики", "монахи" или "сотрудники".

Эти понятия не что иное, как метки, которыми обозначают бедную

личность, чтобы классифицировать ее по отношению к некоторой

системе. Часто реальный или воображаемый мир (например, литература,

особенно фантастика) служат источником понятий, которые кардинально

преобразуются при переводе их в классы. Так, экран моего компьютера

(Маккинтош) совсем не походит на поверхность моего стола, хотя

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

а окна на моем дисплее имеют самое отдаленное отношение к

приспособлениям для презентации чертежей в моей комнате.

Ь Я бы не вынес такого беспорядка у себя на экране.

Суть моделирования реальности не в покорном следовании тому,

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

источника вдохновения и как якоря, который удерживает, когда

стихия программирования грозит лишить нас способности

понимания своей собственной программы.

Здесь полезно предостеречь: новичкам обычно трудно "находить"

классы, но вскоре это преодолевается без каких-либо

неприятностей. Далее обычно приходит этап, когда классы и отношения

наследования между ними бесконтрольно множатся. Здесь уже

возникают проблемы, связанные со сложностью, эффективностью и

ясностью полученной программы. Далеко не каждую отдельную деталь

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

отношение между классами следует представлять как отношение

наследования. Старайтесь не забывать, что цель проекта - смоделировать

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

абстракции. Для больших систем найти компромисс между простотой и

общностью далеко не простая задача.