Бьерн Страуструп - Язык программирования С++. Главы 11-13
Страница 30. Что представляют классы?



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

По сути в системе бывают классы двух видов:
[1] классы, которые прямо отражают понятия области приложения,
    т.е. понятия, которые использует конечный пользователь для
    описания своих задач и возможных решений;
    и
[2] классы, которые являются продуктом самой реализации, т.е.
    отражают понятия, используемые разработчиками и программистами
    для описания способов реализации.
Некоторые из классов, являющихся продуктами реализации, могут
представлять и понятия реального мира. Например, программные и
аппаратные ресурсы системы являются хорошими кандидатами
на роль классов, представляющих область приложения. Это отражает
тот факт, что систему можно рассматривать с нескольких точек
зрения, и то, что с одной является деталью реализации, с
другой может быть понятием области приложения. Хорошо
спроектированная система должна содержать классы, которые
дают возможность рассматривать систему с логически
разных точек зрения. Приведем пример:
  [1] классы, представляющие пользовательские понятия (например,
      легковые машины и грузовики),
  [2] классы, представляющие обобщения пользовательских понятий
      (движущиеся средства),
  [3] классы, представляющие аппаратные ресурсы (например, класс
      управления памятью),
  [4] классы, представляющие системные ресурсы (например,
      выходные потоки),
  [5] классы, используемые для реализации других классов (например,
      списки, очереди, блокировщики) и
  [6] встроенные типы данных и структуры управления.
В больших системах очень трудно сохранять логическое разделение
типов различных классов и поддерживать такое разделение между
различными уровнями абстракции. В приведенном выше перечислении
представлены три уровня абстракции:
  [1+2] представляет пользовательское отражение системы,
  [3+4] представляет машину, на которой будет работать система,
  [5+6] представляет низкоуровневое (со стороны языка программирования)
        отражение реализации.
Чем больше система, тем большее число уровней абстракции необходимо
для ее описания, и тем труднее определять и поддерживать эти уровни
абстракции. Отметим, что таким уровням абстракции есть прямое
соответствие в природе и в различных построениях человеческого
интеллекта. Например, можно рассматривать дом как объект,
состоящий из
  [1] атомов,
  [2] молекул,
  [3] досок и кирпичей,
  [4] полов, потолков и стен;
  [5] комнат.
Пока удается хранить раздельно представления этих уровней абстракции,
можно поддерживать целостное представление о доме. Однако, если
смешать их, возникнет бессмыслица. Например, предложение
"Мой дом состоит из нескольких тысяч фунтов углерода, некоторых
сложных полимеров, из 5000 кирпичей, двух ванных комнат и 13
потолков" - явно абсурдно. Из-за абстрактной природы
программ подобное утверждение о какой-либо сложной программной
системе далеко не всегда воспринимают как бессмыслицу.
   В процессе проектирования выделение понятий из области приложения
в класс вовсе не является простой механической операцией. Обычно
эта задача требует большой проницательности. Заметим, что сами
понятия области приложения являются абстракциями. Например, в
природе не существуют "налогоплательщики", "монахи" или "сотрудники".
Эти понятия не что иное, как метки, которыми обозначают бедную
личность, чтобы классифицировать ее по отношению к некоторой
системе. Часто реальный или воображаемый мир (например, литература,
особенно фантастика) служат источником понятий, которые кардинально
преобразуются при переводе их в классы. Так, экран моего компьютера
(Маккинтош) совсем не походит на поверхность моего стола, хотя
компьютер создавался с целью реализовать понятие "настольный" Ь,
а окна на моем дисплее имеют самое отдаленное отношение к
приспособлениям для презентации чертежей в моей комнате.
Ь Я бы не вынес такого беспорядка у себя на экране.

Суть моделирования реальности не в покорном следовании тому,
что мы видим, а в использовании реальности как начала для проектирования,
источника вдохновения и как якоря, который удерживает, когда
стихия программирования грозит лишить нас способности
понимания своей собственной программы.
   Здесь полезно предостеречь: новичкам обычно трудно "находить"
классы, но вскоре это преодолевается без каких-либо
неприятностей. Далее обычно приходит этап, когда классы и отношения
наследования между ними бесконтрольно множатся. Здесь уже
возникают проблемы, связанные со сложностью, эффективностью и
ясностью полученной программы. Далеко не каждую отдельную деталь
следует представлять отдельным классом, и далеко не каждое
отношение между классами следует представлять как отношение
наследования. Старайтесь не забывать, что цель проекта - смоделировать
систему с подходящим уровнем детализации и подходящим уровнем
абстракции. Для больших систем найти компромисс между простотой и
общностью далеко не простая задача.

 
« Предыдущая статья   Следующая статья »