Страница:
отражаются этот недостаток. Обычно в процессе проектирования
наибольшее внимание уделяется разбиению задачи на процедуры,
производящие требуемые действия. В главе 1 это понятие называлось
процедурным программированием, а в области проектирования оно
именуется как функциональная декомпозиция. Возникает типичный
вопрос "Можно ли использовать С++ совместно с методом проектирования,
базирующимся на функциональной декомпозиции?" Да, можно, но,
вероятнее всего, в результате вы придете к использованию С++ как
просто улучшенного С со всеми указанными выше проблемами. Это
может быть приемлемо на период перехода на новый язык, или для
уже завершенного проектирования, или для подзадач, в которых
использование классов не дает существенных выгод (если учитывать
опыт программирования на С++ к данному моменту), но в общем
случае на большом отрезке времени отказ от свободного
использования классов, связанный с методом функциональной
декомпозиции, никак не совместим с эффективным использованием С++.
Процедурно-ориентированный и объектно-ориентированный
подходы к программированию различаются по своей сути и обычно
ведут к совершенно разным решениям одной задачи. Этот вывод
верен как для стадии реализации, так и для стадии проектирования:
вы концентрируете внимание или на предпринимаемых действиях, или на
представляемых сущностях, но не на том и другом одновременно.
Тогда почему метод объектно-ориентированного проектирования
предпочтительнее метода функциональной декомпозиции?
Главная причина в том, что функциональная декомпозиция не дает
достаточной абстракции данных. А отсюда уже следует, что проект
будет
- менее податливым к изменениям,
- менее приспособленным для использования различных вспомогательных
средств,
- менее пригодным для параллельного развития и
- менее пригодным для параллельного выполнения.
Дело в том, что функциональная декомпозиция вынуждает объявлять
"важные" данные глобальными, поскольку, если система структурирована
как дерево функций, всякое данное, доступное двум функциям, должно
быть глобальным по отношению к ним. Это приводит к тому, что
"важные" данные "всплывают" к вершине дерева, по
мере того как все большее число функций требует доступа к нимЬ.
Ь В точности так же происходит в случае иерархии классов с одним
корнем, когда "важные" данные всплывают по направлению к базовому
классу.
Когда мы концентрируем внимание на описаниях классов, заключающих
определенные данные в оболочку, то зависимости между различными
частями программы выражены явно и можно их проследить. Еще более
важно то, что при таком подходе уменьшается число зависимостей
в системе за счет лучшей расстановки ссылок на данные.
Однако, некоторые задачи лучше решаются с помощью набора
процедур. Смысл "объектно-ориентированного" проектирования не в
том, чтобы удалить все глобальные процедуры из программы или
не иметь в системе процедурно-ориентированных частей. Основная
идея скорее в том, что классы, а не глобальные процедуры становятся
главным объектом внимания на стадии проектирования. Использование
процедурного стиля должно быть осознанным решением, а не решением,
принимаемым по умолчанию. Как классы, так и процедуры следует
применять сообразно области приложения, а не просто как
неизменные методы проектирования.
Рассмотрим вариант 2 - проект, который игнорирует наследование. В этом
случае в окончательной программе просто не используются возможности
основного средства С++, хотя и получаются определенные выгоды при
использовании С++ по сравнению с использованием языков С, Паскаль,
Фортран, Кобол и т.п. Обычные доводы в пользу этого, помимо инерции,
утверждения, что "наследование - это деталь реализации", или "наследование
препятствует упрятыванию информации", или "наследование затрудняет
взаимодействие с другими системами программирования".
Считать наследование всего лишь деталью реализации - значит
игнорировать иерархию классов, которая может непосредственно
моделировать отношения между понятиями в области приложения. Такие
отношения должны быть явно выражены в проекте, чтобы дать
возможность разработчику продумать их.
Сильные доводы можно привести в пользу исключения наследования
из тех частей программы на С++, которые непосредственно взаимодействуют
с программами, написанными на других языках. Но это не является
достаточной причиной, чтобы отказаться от наследования в системе
в целом, это просто довод в пользу того, чтобы аккуратно определить
и инкапсулировать программный интерфейс с "внешним миром".
Аналогично, чтобы избавиться от беспокойства, вызванного путаницей с
упрятыванием информации при наличии наследования, надо осторожно
использовать виртуальные функции и закрытые члены, но не
отказываться от наследования.
Существует достаточно много ситуаций, когда использование
наследования не дает явных выгод, но политика
"никакого наследования" приведет к менее понятной и менее гибкой
системе, в которой наследование "подделывается" с помощью
более традиционных конструкций языка и проектирования.
Для больших проектов это существенно. Более того,
вполне возможно, что несмотря на такую политику, наследование
все равно будет использоваться, поскольку программисты, работающие
на С++, найдут убедительные доводы в пользу проектирования с учетом
наследования в различных частях системы. Таким образом, политика
"никакого наследования" приведет лишь к тому, что в системе будет
отсутствовать целостная общая структура, а использование иерархии
классов будет ограничено определенными подсистемами.
Иными словами, будьте непредубежденными. Иерархия классов
не является обязательной частью всякой хорошей программы, но есть
масса ситуаций, когда она может помочь как в понимании области
приложения, так и в формулировании решений. Утверждение, что
наследование может неправильно или чрезмерно использоваться,
служит только доводом в пользу осторожности, а вовсе не в пользу
отказа от него.
Рассмотрим вариант 3, относящийся к проекту, в котором игнорируется
статический контроль типов. Распространенные доводы в пользу отказа
на стадии проектирования от статического контроля типов сводятся
к тому, что "типы - это продукт языков программирования", или что
"более естественно рассуждать об объектах, не заботясь о типах",
или "статический контроль типов вынуждает нас думать о реализации
на слишком раннем этапе". Такой подход вполне допустим до тех пор,
пока он работает и не приносит вреда. Вполне разумно на стадии
проектирования не заботиться о деталях проверки типов, и часто
вполне допустимо на стадии анализа и начальных стадиях проектирования
полностью забыть о вопросах, связанных с типами. В то же время,
классы и иерархии классов очень полезны на стадии проектирования,
в частности, они дают нам большую определенность понятий, позволяют
точно задать взаимоотношения между понятиями и помогают рассуждать
о понятиях. По мере развития проекта эта определенность и точность
преобразуется во все более конкретные утверждения о классах и их
интерфейсах.
Важно понимать, что точно определенные и строго типизированные
интерфейсы являются фундаментальным средством проектирования. Язык
С++ был создан как раз с учетом этого. Строго типизированный
интерфейс гарантирует, что только совместимые части
программы могут быть скомпилированы и скомпонованы воедино, и тем
самым позволяет делать относительно строгие допущения об этих частях.
Эти допущения обеспечиваются системой типов языка.
В результате сводятся к минимуму проверки на этапе
выполнения, что повышает эффективность и приводит к значительному
сокращению фазы интеграции частей проекта, реализованных разными
программистами. Реальный положительный опыт
интеграции системы со строго типизированными интерфейсами привел
к тому, что вопросы интеграции вообще не фигурируют среди основных
тем этой главы.
Рассмотрим следующую аналогию: в физическом мире мы постоянно
соединяем различные устройства, и существует кажущееся бесконечным
число стандартов на соединения. Главная особенность этих соединений:
они специально спроектированы таким образом, чтобы сделать невозможным
соединение двух устройств, нерассчитанных на него,
то есть соединение должно быть сделано единственным
правильным способом. Вы не можете подсоединить электробритву к
розетке с высоким напряжением. Если бы вы смогли сделать это, то
сожгли бы бритву или сгорели сами. Масса изобретательности была
проявлена, чтобы добиться невозможности соединения двух
несовместимых устройств. Альтернативой одновременного использования
нескольких несовместимых устройств может послужить такое устройство,
которое само себя защищает от несовместимых с ним устройств,
подключающихся к его входу. Хорошим примером может служить стабилизатор
напряжения. Поскольку идеальную совместимость устройств нельзя
гарантировать только на "уровне соединения", иногда требуется более
дорогая защита в электрической цепи, которая позволяет в динамике
приспособиться или (и) защититься от скачков напряжения.
Здесь практически прямая аналогия: статический контроль
типов эквивалентен совместимости на уровне соединения, а динамические
проверки соответствуют защите или адаптации в цепи. Результатом
неудачного контроля как в физическом, так и в программном мире будет
серьезный ущерб. В больших системах используются оба вида контроля.
На раннем этапе проектирования вполне достаточно простого утверждения:
"Эти два устройства необходимо соединить"; но скоро становится
существенным, как именно следует их соединить: "Какие гарантии
дает соединение относительно поведения устройств?", или
"Возникновение каких ошибочных ситуаций возможно?", или
"Какова приблизительная цена такого соединения?"
Применение "статической типизации" не ограничивается программным
миром. В физике и инженерных науках повсеместно распространены
единицы измерения (метры, килограммы, секунды), чтобы избежать
смешивания несовместимых сущностей.
В нашем описании шагов проектирования в $$11.3.3 типы
появляются на сцене уже на шаге 2 (очевидно, после несколько
искусственного их рассмотрения на шаге 1) и становятся главной
темой шага 4.
Статически контролируемые интерфейсы - это
основное средство взаимодействия программных частей системы
на С++, созданных разными группами, а описание интерфейсов этих
частей (с учетом точных определений типов) становится основным
способом сотрудничества между отдельными группами программистов.
Эти интерфейсы являются основным результатом процесса проектирования
и служат главным средством общения между разработчиками и
программистами.
Отказ от этого приводит к проектам, в которых неясна
структура программы, контроль ошибок отложен на стадию
выполнения, которые трудно хорошо реализовать на С++.
Рассмотрим интерфейс, описанный с помощью "объектов",
определяющих себя самостоятельно. Возможно, например, такое описание:
"Функция f() имеет аргумент, который должен быть самолетом"
(что проверяется самой функцией во время ее выполнения), в отличие
от описания "Функция f() имеет аргумент, тип которого есть самолет"
(что проверяется транслятором). Первое описание является существенно
недостаточным описанием интерфейса, т.к. приводит к динамической проверке
вместо статического контроля. Аналогичный вывод из примера с
самолетом сделан в $$1.5.2. Здесь использованы более точные
спецификации, и использован шаблон типа и виртуальные функции взамен
неограниченных динамических проверок для того, чтобы перенести
выявление ошибок с этапа выполнения на этап трансляции. Различие
времен работы программ с динамическим и статическим контролем
может быть весьма значительным, обычно оно находится в диапазоне
от 3 до 10 раз.
Но не следует впадать в другую крайность. Нельзя обнаружить
все ошибки с помощью статического контроля. Например, даже
программы с самым обширным статическим контролем уязвимы к сбоям
аппаратуры. Но все же, в идеале нужно иметь большое разнообразие
интерфейсов со статической типизацией с помощью типов из области
приложения, см. $$12.4.
Может получиться, что проект, совершенно
разумный на абстрактном уровне, столкнется с серьезными
проблемами, если не учитывает ограничения базовых средств, в
данном случае С++. Например, использование имен, а не типов для
структурирования системы приведет к ненужным проблемам для
системы типов С++ и, тем самым, может стать причиной ошибок и
накладных расходов при выполнении. Рассмотрим три класса:
class X { // pseudo code, not C++
f()
g()
}
class Y {
g()
h()
}
class Z {
h()
f()
}
используемые некоторыми функциями бестипового проекта:
k(a, b, c) // pseudo code, not C++
{
a.f()
b.g()
c.h()
}
Здесь обращения
X x
Y y
Z z
k(x,y,z) // ok
k(z,x,y) // ok
будут успешными, поскольку k() просто требует, чтобы ее первый
параметр имел операцию f(), второй параметр - операцию g(), а
третий параметр - операцию h(). С другой стороны обращения
k(y,x,z); // fail
k(x,z,y); // fail
завершатся неудачно. Этот пример допускает совершенно разумные
реализации на языках с полным динамическим контролем (например,
Smalltalk или CLOS), но в С++ он не имеет прямого
представления, поскольку язык требует, чтобы общность типов была
реализована как отношение к базовому классу. Обычно примеры,
подобные этому, можно представить на С++, если записывать утверждения
об общности с помощью явных определений классов, но это потребует
большого хитроумия и вспомогательных средств. Можно сделать,
например, так:
class F {
virtual void f();
};
class G {
virtual void g();
};
class H {
virtual void h();
};
class X : public virtual F, public virtual G {
void f();
void g();
};
class Y : public virtual G, public virtual H {
void g();
void h();
};
class Z : public virtual H, public virtual F {
void h();
void f();
};
k(const F& a, const G& b, const H& c)
{
a.f();
b.g();
c.h();
}
main()
{
X x;
Y y;
Z z;
k(x,y,z); // ok
k(z,x,y); // ok
k(y,x,z); // error F required for first argument
k(x,z,y); // error G required for second argument
}
Обратите внимание, что сделав предположения k() о своих аргументах
явными, мы переместили контроль ошибок с этапа выполнения на этап
трансляции. Сложные примеры, подобные приведенному, возникают,
когда пытаются реализовать на С++ проекты, сделанные на основе
опыта работы с другими системами типов. Обычно это возможно,
но в результате получается неестественная и неэффективная программа.
Такое несовпадение между приемами проектирования и языком
программирования можно сравнить с несовпадением при пословном
переводе с одного естественного языка на другой. Ведь английский
с немецкой грамматикой выглядит столь же неуклюже, как и немецкий
с английской грамматикой, но оба языка могут быть доступны
пониманию того, кто бегло говорит на одном из них.
Этот пример подтверждает тот вывод, что классы в программе являются
конкретным воплощением понятий, используемых при проектировании,
поэтому нечеткие отношения между классами приводят к нечеткости
основных понятий проектирования.
Переход на новые методы работы может быть мучителен для любой
организации. Раскол внутри нее и расхождения между сотрудниками могут
быть значительными. Но резкий решительный переход, способный в одночасье
превратить эффективных и квалифицированных сторонников "старой школы"
в неэффективных новичков "новой школы" обычно неприемлем. В то же
время, нельзя достичь больших высот без изменений, а
значительные изменения обычно связаны с риском.
Язык С++ создавался с целью сократить такой риск за счет
постепенного введения новых методов. Хотя очевидно, что наибольшие
преимущества при использовании С++ достигаются за счет абстракции
данных, объектно-ориентированного программирования и
объектно-ориентированного проектирования, совершенно неочевидно,
что быстрее всего достичь этого можно решительным
разрывом с прошлым. Вряд ли такой явный разрыв будет возможен,
обычно стремление к усовершенствованиям сдерживается или должно
сдерживаться, чтобы переход к ним был управляемым. Нужно учитывать
следующее:
- Разработчикам и программистам требуется время для овладения
новыми методами.
- Новые программы должны взаимодействовать со старыми программами.
- Старые программы нужно сопровождать (часто бесконечно).
- Работа по текущим проектам и программам должна быть
выполнена в срок.
- Средства, рассчитанные на новые методы, нужно адаптировать к
локальному окружению.
Здесь рассматриваются как раз ситуации, связанные с перечисленными
требованиями. Легко недооценить два первых требования.
Поскольку в С++ возможны несколько схем программирования,
язык допускает постепенный переход на него, используя
следующие преимущества такого перехода:
- Изучая С++, программисты могут продолжать работать.
- В окружении, бедном на программные средства, использование С++
может принести значительные выгоды.
- Программы, написанные на С++, могут хорошо взаимодействовать
с программами, написанными на С или других традиционных языках.
- Язык имеет большое подмножество, совместимое с С.
Идея заключается в постепенном переходе программиста с
традиционного языка на С++: вначале он программирует на С++
в традиционном процедурном стиле, затем с помощью методов абстракции
данных, и наконец, когда овладеет языком и связанными с ним средствами,
полностью переходит на объектно-ориентированное программирование.
Заметим, что хорошо спроектированную библиотеку использовать намного
проще, чем проектировать и реализовывать, поэтому даже с первых своих
шагов новичок может получить преимущества, используя более
развитые средства С++.
Идея постепенного, пошагового овладения С++, а также возможность
смешивать программы на С++ с программами, написанными на языках,
не имеющих средств абстракции данных и объектно-ориентированного
программирования, естественно приводит к проекту, имеющему
гибридный стиль. Большинство интерфейсов можно пока оставить
на процедурном уровне, поскольку что-либо более сложное не
принесет немедленного выигрыша. Например, обращение к стандартной
библиотеке math из С определяется на С++ так:
extern "C" {
#include <math.h>
}
и стандартные математические функции из библиотеки можно использовать
так же, как и в С. Для всех основных библиотек такое включение
должно быть сделано теми, кто поставляет библиотеки, так что
программист на С++ даже не будет знать, на каком языке реализована
библиотечная функция. Использование библиотек, написанных на таких
языках как С, является первым и вначале самым важным способом
повторного использования на С++.
На следующем шаге, когда станут необходимы более сложные
приемы, средства, реализованные на таких языках как С или Фортран,
представляются в виде классов за счет инкапсуляции структур данных
и функций в интерфейс классов С++. Простым примером
введения более высокого семантического уровня за счет перехода
от уровня процедур плюс структур данных к уровню абстракции данных
может служить класс строк из $$7.6. Здесь за счет инкапсуляции
символьных строк и стандартных строковых функций С
получается новый строковый тип, который гораздо проще использовать.
Подобным образом можно включить в иерархию классов любой
встроенный или отдельно определенный тип. Например, тип int
можно включить в иерархию классов так:
class Int : public My_object {
int i;
public:
// definition of operations
// see exercises [8]-[11] in section 7.14 for ideas
// определения операций получаются в упражнениях [8]-[11]
// за идеями обратитесь к разделу 7.14
};
Так следует делать, если действительно есть потребность
включить такие типы в иерархию.
Обратно, классы С++ можно представить в программе на С или
Фортране как функции и структуры данных. Например:
class myclass {
// representation
public:
void f();
T1 g(T2);
// ...
};
extern "C" { // map myclass into C callable functions:
void myclass_f(myclass* p) { p->f(); }
T1 myclass_g(myclass* p, T2 a) { return p->g(a); }
// ...
};
В С-программе следует определить эти функции в заголовочном файле
следующим образом:
// in C header file
extern void myclass_f(struct myclass*);
extern T1 myclass_g(struct myclass*, T2);
Такой подход позволяет разработчику на С++, если у него уже есть
запас программ, написанных на языках, в которых отсутствуют понятия
абстракции данных и иерархии классов, постепенно приобщаться к этим
понятиям, даже при том требовании, что окончательную версии программы
можно будет вызывать из традиционных процедурных языков.
Основное положение объектно-ориентированного проектирования и
программирования заключается в том, что программа служит моделью
некоторых понятий реальности. Классы в программе представляют
основные понятия области приложения и, в частности, основные
понятия самого процесса моделирования реальности. Объекты классов
представляют предметы реального мира и продукты процесса
реализации.
Мы рассмотрим структуру программы с точки зрения следующих
взаимоотношений между классами:
- отношения наследования,
- отношения принадлежности,
- отношения использования и
- запрограммированные отношения.
При рассмотрении этих отношений неявно предполагается, что их анализ
является узловым моментом в проекте системы. В $$12.4 исследуются
свойства, которые делают класс и его интерфейс полезными для
представления понятий. Вообще говоря, в идеале, зависимость класса
от остального мира должна быть минимальна и четко определена, а
сам класс должен через интерфейс открывать лишь минимальный объем
информации для остального мира.
Подчеркнем, что класс в С++ является типом, поэтому сами классы
и взаимоотношения между ними обеспечены значительной поддержкой
со стороны транслятора и в общем случае поддаются статическому анализу.
По сути в системе бывают классы двух видов:
[1] классы, которые прямо отражают понятия области приложения,
т.е. понятия, которые использует конечный пользователь для
описания своих задач и возможных решений;
и
[2] классы, которые являются продуктом самой реализации, т.е.
отражают понятия, используемые разработчиками и программистами
для описания способов реализации.
Некоторые из классов, являющихся продуктами реализации, могут
представлять и понятия реального мира. Например, программные и
аппаратные ресурсы системы являются хорошими кандидатами
на роль классов, представляющих область приложения. Это отражает
тот факт, что систему можно рассматривать с нескольких точек
зрения, и то, что с одной является деталью реализации, с
другой может быть понятием области приложения. Хорошо
спроектированная система должна содержать классы, которые
дают возможность рассматривать систему с логически
разных точек зрения. Приведем пример:
[1] классы, представляющие пользовательские понятия (например,
легковые машины и грузовики),
[2] классы, представляющие обобщения пользовательских понятий
(движущиеся средства),
[3] классы, представляющие аппаратные ресурсы (например, класс
управления памятью),
[4] классы, представляющие системные ресурсы (например,
выходные потоки),
[5] классы, используемые для реализации других классов (например,
списки, очереди, блокировщики) и
[6] встроенные типы данных и структуры управления.
В больших системах очень трудно сохранять логическое разделение
типов различных классов и поддерживать такое разделение между
различными уровнями абстракции. В приведенном выше перечислении
представлены три уровня абстракции:
[1+2] представляет пользовательское отражение системы,
[3+4] представляет машину, на которой будет работать система,
[5+6] представляет низкоуровневое (со стороны языка программирования)
отражение реализации.
Чем больше система, тем большее число уровней абстракции необходимо
для ее описания, и тем труднее определять и поддерживать эти уровни
абстракции. Отметим, что таким уровням абстракции есть прямое
соответствие в природе и в различных построениях человеческого
интеллекта. Например, можно рассматривать дом как объект,
состоящий из
[1] атомов,
[2] молекул,
[3] досок и кирпичей,
[4] полов, потолков и стен;
[5] комнат.
Пока удается хранить раздельно представления этих уровней абстракции,
можно поддерживать целостное представление о доме. Однако, если
смешать их, возникнет бессмыслица. Например, предложение
"Мой дом состоит из нескольких тысяч фунтов углерода, некоторых
сложных полимеров, из 5000 кирпичей, двух ванных комнат и 13
потолков" - явно абсурдно. Из-за абстрактной природы
программ подобное утверждение о какой-либо сложной программной
системе далеко не всегда воспринимают как бессмыслицу.
В процессе проектирования выделение понятий из области приложения
в класс вовсе не является простой механической операцией. Обычно
эта задача требует большой проницательности. Заметим, что сами
понятия области приложения являются абстракциями. Например, в
природе не существуют "налогоплательщики", "монахи" или "сотрудники".
Эти понятия не что иное, как метки, которыми обозначают бедную
личность, чтобы классифицировать ее по отношению к некоторой
системе. Часто реальный или воображаемый мир (например, литература,
особенно фантастика) служат источником понятий, которые кардинально
преобразуются при переводе их в классы. Так, экран моего компьютера
(Маккинтош) совсем не походит на поверхность моего стола, хотя
компьютер создавался с целью реализовать понятие "настольный" Ь,
наибольшее внимание уделяется разбиению задачи на процедуры,
производящие требуемые действия. В главе 1 это понятие называлось
процедурным программированием, а в области проектирования оно
именуется как функциональная декомпозиция. Возникает типичный
вопрос "Можно ли использовать С++ совместно с методом проектирования,
базирующимся на функциональной декомпозиции?" Да, можно, но,
вероятнее всего, в результате вы придете к использованию С++ как
просто улучшенного С со всеми указанными выше проблемами. Это
может быть приемлемо на период перехода на новый язык, или для
уже завершенного проектирования, или для подзадач, в которых
использование классов не дает существенных выгод (если учитывать
опыт программирования на С++ к данному моменту), но в общем
случае на большом отрезке времени отказ от свободного
использования классов, связанный с методом функциональной
декомпозиции, никак не совместим с эффективным использованием С++.
Процедурно-ориентированный и объектно-ориентированный
подходы к программированию различаются по своей сути и обычно
ведут к совершенно разным решениям одной задачи. Этот вывод
верен как для стадии реализации, так и для стадии проектирования:
вы концентрируете внимание или на предпринимаемых действиях, или на
представляемых сущностях, но не на том и другом одновременно.
Тогда почему метод объектно-ориентированного проектирования
предпочтительнее метода функциональной декомпозиции?
Главная причина в том, что функциональная декомпозиция не дает
достаточной абстракции данных. А отсюда уже следует, что проект
будет
- менее податливым к изменениям,
- менее приспособленным для использования различных вспомогательных
средств,
- менее пригодным для параллельного развития и
- менее пригодным для параллельного выполнения.
Дело в том, что функциональная декомпозиция вынуждает объявлять
"важные" данные глобальными, поскольку, если система структурирована
как дерево функций, всякое данное, доступное двум функциям, должно
быть глобальным по отношению к ним. Это приводит к тому, что
"важные" данные "всплывают" к вершине дерева, по
мере того как все большее число функций требует доступа к нимЬ.
Ь В точности так же происходит в случае иерархии классов с одним
корнем, когда "важные" данные всплывают по направлению к базовому
классу.
Когда мы концентрируем внимание на описаниях классов, заключающих
определенные данные в оболочку, то зависимости между различными
частями программы выражены явно и можно их проследить. Еще более
важно то, что при таком подходе уменьшается число зависимостей
в системе за счет лучшей расстановки ссылок на данные.
Однако, некоторые задачи лучше решаются с помощью набора
процедур. Смысл "объектно-ориентированного" проектирования не в
том, чтобы удалить все глобальные процедуры из программы или
не иметь в системе процедурно-ориентированных частей. Основная
идея скорее в том, что классы, а не глобальные процедуры становятся
главным объектом внимания на стадии проектирования. Использование
процедурного стиля должно быть осознанным решением, а не решением,
принимаемым по умолчанию. Как классы, так и процедуры следует
применять сообразно области приложения, а не просто как
неизменные методы проектирования.
Рассмотрим вариант 2 - проект, который игнорирует наследование. В этом
случае в окончательной программе просто не используются возможности
основного средства С++, хотя и получаются определенные выгоды при
использовании С++ по сравнению с использованием языков С, Паскаль,
Фортран, Кобол и т.п. Обычные доводы в пользу этого, помимо инерции,
утверждения, что "наследование - это деталь реализации", или "наследование
препятствует упрятыванию информации", или "наследование затрудняет
взаимодействие с другими системами программирования".
Считать наследование всего лишь деталью реализации - значит
игнорировать иерархию классов, которая может непосредственно
моделировать отношения между понятиями в области приложения. Такие
отношения должны быть явно выражены в проекте, чтобы дать
возможность разработчику продумать их.
Сильные доводы можно привести в пользу исключения наследования
из тех частей программы на С++, которые непосредственно взаимодействуют
с программами, написанными на других языках. Но это не является
достаточной причиной, чтобы отказаться от наследования в системе
в целом, это просто довод в пользу того, чтобы аккуратно определить
и инкапсулировать программный интерфейс с "внешним миром".
Аналогично, чтобы избавиться от беспокойства, вызванного путаницей с
упрятыванием информации при наличии наследования, надо осторожно
использовать виртуальные функции и закрытые члены, но не
отказываться от наследования.
Существует достаточно много ситуаций, когда использование
наследования не дает явных выгод, но политика
"никакого наследования" приведет к менее понятной и менее гибкой
системе, в которой наследование "подделывается" с помощью
более традиционных конструкций языка и проектирования.
Для больших проектов это существенно. Более того,
вполне возможно, что несмотря на такую политику, наследование
все равно будет использоваться, поскольку программисты, работающие
на С++, найдут убедительные доводы в пользу проектирования с учетом
наследования в различных частях системы. Таким образом, политика
"никакого наследования" приведет лишь к тому, что в системе будет
отсутствовать целостная общая структура, а использование иерархии
классов будет ограничено определенными подсистемами.
Иными словами, будьте непредубежденными. Иерархия классов
не является обязательной частью всякой хорошей программы, но есть
масса ситуаций, когда она может помочь как в понимании области
приложения, так и в формулировании решений. Утверждение, что
наследование может неправильно или чрезмерно использоваться,
служит только доводом в пользу осторожности, а вовсе не в пользу
отказа от него.
Рассмотрим вариант 3, относящийся к проекту, в котором игнорируется
статический контроль типов. Распространенные доводы в пользу отказа
на стадии проектирования от статического контроля типов сводятся
к тому, что "типы - это продукт языков программирования", или что
"более естественно рассуждать об объектах, не заботясь о типах",
или "статический контроль типов вынуждает нас думать о реализации
на слишком раннем этапе". Такой подход вполне допустим до тех пор,
пока он работает и не приносит вреда. Вполне разумно на стадии
проектирования не заботиться о деталях проверки типов, и часто
вполне допустимо на стадии анализа и начальных стадиях проектирования
полностью забыть о вопросах, связанных с типами. В то же время,
классы и иерархии классов очень полезны на стадии проектирования,
в частности, они дают нам большую определенность понятий, позволяют
точно задать взаимоотношения между понятиями и помогают рассуждать
о понятиях. По мере развития проекта эта определенность и точность
преобразуется во все более конкретные утверждения о классах и их
интерфейсах.
Важно понимать, что точно определенные и строго типизированные
интерфейсы являются фундаментальным средством проектирования. Язык
С++ был создан как раз с учетом этого. Строго типизированный
интерфейс гарантирует, что только совместимые части
программы могут быть скомпилированы и скомпонованы воедино, и тем
самым позволяет делать относительно строгие допущения об этих частях.
Эти допущения обеспечиваются системой типов языка.
В результате сводятся к минимуму проверки на этапе
выполнения, что повышает эффективность и приводит к значительному
сокращению фазы интеграции частей проекта, реализованных разными
программистами. Реальный положительный опыт
интеграции системы со строго типизированными интерфейсами привел
к тому, что вопросы интеграции вообще не фигурируют среди основных
тем этой главы.
Рассмотрим следующую аналогию: в физическом мире мы постоянно
соединяем различные устройства, и существует кажущееся бесконечным
число стандартов на соединения. Главная особенность этих соединений:
они специально спроектированы таким образом, чтобы сделать невозможным
соединение двух устройств, нерассчитанных на него,
то есть соединение должно быть сделано единственным
правильным способом. Вы не можете подсоединить электробритву к
розетке с высоким напряжением. Если бы вы смогли сделать это, то
сожгли бы бритву или сгорели сами. Масса изобретательности была
проявлена, чтобы добиться невозможности соединения двух
несовместимых устройств. Альтернативой одновременного использования
нескольких несовместимых устройств может послужить такое устройство,
которое само себя защищает от несовместимых с ним устройств,
подключающихся к его входу. Хорошим примером может служить стабилизатор
напряжения. Поскольку идеальную совместимость устройств нельзя
гарантировать только на "уровне соединения", иногда требуется более
дорогая защита в электрической цепи, которая позволяет в динамике
приспособиться или (и) защититься от скачков напряжения.
Здесь практически прямая аналогия: статический контроль
типов эквивалентен совместимости на уровне соединения, а динамические
проверки соответствуют защите или адаптации в цепи. Результатом
неудачного контроля как в физическом, так и в программном мире будет
серьезный ущерб. В больших системах используются оба вида контроля.
На раннем этапе проектирования вполне достаточно простого утверждения:
"Эти два устройства необходимо соединить"; но скоро становится
существенным, как именно следует их соединить: "Какие гарантии
дает соединение относительно поведения устройств?", или
"Возникновение каких ошибочных ситуаций возможно?", или
"Какова приблизительная цена такого соединения?"
Применение "статической типизации" не ограничивается программным
миром. В физике и инженерных науках повсеместно распространены
единицы измерения (метры, килограммы, секунды), чтобы избежать
смешивания несовместимых сущностей.
В нашем описании шагов проектирования в $$11.3.3 типы
появляются на сцене уже на шаге 2 (очевидно, после несколько
искусственного их рассмотрения на шаге 1) и становятся главной
темой шага 4.
Статически контролируемые интерфейсы - это
основное средство взаимодействия программных частей системы
на С++, созданных разными группами, а описание интерфейсов этих
частей (с учетом точных определений типов) становится основным
способом сотрудничества между отдельными группами программистов.
Эти интерфейсы являются основным результатом процесса проектирования
и служат главным средством общения между разработчиками и
программистами.
Отказ от этого приводит к проектам, в которых неясна
структура программы, контроль ошибок отложен на стадию
выполнения, которые трудно хорошо реализовать на С++.
Рассмотрим интерфейс, описанный с помощью "объектов",
определяющих себя самостоятельно. Возможно, например, такое описание:
"Функция f() имеет аргумент, который должен быть самолетом"
(что проверяется самой функцией во время ее выполнения), в отличие
от описания "Функция f() имеет аргумент, тип которого есть самолет"
(что проверяется транслятором). Первое описание является существенно
недостаточным описанием интерфейса, т.к. приводит к динамической проверке
вместо статического контроля. Аналогичный вывод из примера с
самолетом сделан в $$1.5.2. Здесь использованы более точные
спецификации, и использован шаблон типа и виртуальные функции взамен
неограниченных динамических проверок для того, чтобы перенести
выявление ошибок с этапа выполнения на этап трансляции. Различие
времен работы программ с динамическим и статическим контролем
может быть весьма значительным, обычно оно находится в диапазоне
от 3 до 10 раз.
Но не следует впадать в другую крайность. Нельзя обнаружить
все ошибки с помощью статического контроля. Например, даже
программы с самым обширным статическим контролем уязвимы к сбоям
аппаратуры. Но все же, в идеале нужно иметь большое разнообразие
интерфейсов со статической типизацией с помощью типов из области
приложения, см. $$12.4.
Может получиться, что проект, совершенно
разумный на абстрактном уровне, столкнется с серьезными
проблемами, если не учитывает ограничения базовых средств, в
данном случае С++. Например, использование имен, а не типов для
структурирования системы приведет к ненужным проблемам для
системы типов С++ и, тем самым, может стать причиной ошибок и
накладных расходов при выполнении. Рассмотрим три класса:
class X { // pseudo code, not C++
f()
g()
}
class Y {
g()
h()
}
class Z {
h()
f()
}
используемые некоторыми функциями бестипового проекта:
k(a, b, c) // pseudo code, not C++
{
a.f()
b.g()
c.h()
}
Здесь обращения
X x
Y y
Z z
k(x,y,z) // ok
k(z,x,y) // ok
будут успешными, поскольку k() просто требует, чтобы ее первый
параметр имел операцию f(), второй параметр - операцию g(), а
третий параметр - операцию h(). С другой стороны обращения
k(y,x,z); // fail
k(x,z,y); // fail
завершатся неудачно. Этот пример допускает совершенно разумные
реализации на языках с полным динамическим контролем (например,
Smalltalk или CLOS), но в С++ он не имеет прямого
представления, поскольку язык требует, чтобы общность типов была
реализована как отношение к базовому классу. Обычно примеры,
подобные этому, можно представить на С++, если записывать утверждения
об общности с помощью явных определений классов, но это потребует
большого хитроумия и вспомогательных средств. Можно сделать,
например, так:
class F {
virtual void f();
};
class G {
virtual void g();
};
class H {
virtual void h();
};
class X : public virtual F, public virtual G {
void f();
void g();
};
class Y : public virtual G, public virtual H {
void g();
void h();
};
class Z : public virtual H, public virtual F {
void h();
void f();
};
k(const F& a, const G& b, const H& c)
{
a.f();
b.g();
c.h();
}
main()
{
X x;
Y y;
Z z;
k(x,y,z); // ok
k(z,x,y); // ok
k(y,x,z); // error F required for first argument
k(x,z,y); // error G required for second argument
}
Обратите внимание, что сделав предположения k() о своих аргументах
явными, мы переместили контроль ошибок с этапа выполнения на этап
трансляции. Сложные примеры, подобные приведенному, возникают,
когда пытаются реализовать на С++ проекты, сделанные на основе
опыта работы с другими системами типов. Обычно это возможно,
но в результате получается неестественная и неэффективная программа.
Такое несовпадение между приемами проектирования и языком
программирования можно сравнить с несовпадением при пословном
переводе с одного естественного языка на другой. Ведь английский
с немецкой грамматикой выглядит столь же неуклюже, как и немецкий
с английской грамматикой, но оба языка могут быть доступны
пониманию того, кто бегло говорит на одном из них.
Этот пример подтверждает тот вывод, что классы в программе являются
конкретным воплощением понятий, используемых при проектировании,
поэтому нечеткие отношения между классами приводят к нечеткости
основных понятий проектирования.
Переход на новые методы работы может быть мучителен для любой
организации. Раскол внутри нее и расхождения между сотрудниками могут
быть значительными. Но резкий решительный переход, способный в одночасье
превратить эффективных и квалифицированных сторонников "старой школы"
в неэффективных новичков "новой школы" обычно неприемлем. В то же
время, нельзя достичь больших высот без изменений, а
значительные изменения обычно связаны с риском.
Язык С++ создавался с целью сократить такой риск за счет
постепенного введения новых методов. Хотя очевидно, что наибольшие
преимущества при использовании С++ достигаются за счет абстракции
данных, объектно-ориентированного программирования и
объектно-ориентированного проектирования, совершенно неочевидно,
что быстрее всего достичь этого можно решительным
разрывом с прошлым. Вряд ли такой явный разрыв будет возможен,
обычно стремление к усовершенствованиям сдерживается или должно
сдерживаться, чтобы переход к ним был управляемым. Нужно учитывать
следующее:
- Разработчикам и программистам требуется время для овладения
новыми методами.
- Новые программы должны взаимодействовать со старыми программами.
- Старые программы нужно сопровождать (часто бесконечно).
- Работа по текущим проектам и программам должна быть
выполнена в срок.
- Средства, рассчитанные на новые методы, нужно адаптировать к
локальному окружению.
Здесь рассматриваются как раз ситуации, связанные с перечисленными
требованиями. Легко недооценить два первых требования.
Поскольку в С++ возможны несколько схем программирования,
язык допускает постепенный переход на него, используя
следующие преимущества такого перехода:
- Изучая С++, программисты могут продолжать работать.
- В окружении, бедном на программные средства, использование С++
может принести значительные выгоды.
- Программы, написанные на С++, могут хорошо взаимодействовать
с программами, написанными на С или других традиционных языках.
- Язык имеет большое подмножество, совместимое с С.
Идея заключается в постепенном переходе программиста с
традиционного языка на С++: вначале он программирует на С++
в традиционном процедурном стиле, затем с помощью методов абстракции
данных, и наконец, когда овладеет языком и связанными с ним средствами,
полностью переходит на объектно-ориентированное программирование.
Заметим, что хорошо спроектированную библиотеку использовать намного
проще, чем проектировать и реализовывать, поэтому даже с первых своих
шагов новичок может получить преимущества, используя более
развитые средства С++.
Идея постепенного, пошагового овладения С++, а также возможность
смешивать программы на С++ с программами, написанными на языках,
не имеющих средств абстракции данных и объектно-ориентированного
программирования, естественно приводит к проекту, имеющему
гибридный стиль. Большинство интерфейсов можно пока оставить
на процедурном уровне, поскольку что-либо более сложное не
принесет немедленного выигрыша. Например, обращение к стандартной
библиотеке math из С определяется на С++ так:
extern "C" {
#include <math.h>
}
и стандартные математические функции из библиотеки можно использовать
так же, как и в С. Для всех основных библиотек такое включение
должно быть сделано теми, кто поставляет библиотеки, так что
программист на С++ даже не будет знать, на каком языке реализована
библиотечная функция. Использование библиотек, написанных на таких
языках как С, является первым и вначале самым важным способом
повторного использования на С++.
На следующем шаге, когда станут необходимы более сложные
приемы, средства, реализованные на таких языках как С или Фортран,
представляются в виде классов за счет инкапсуляции структур данных
и функций в интерфейс классов С++. Простым примером
введения более высокого семантического уровня за счет перехода
от уровня процедур плюс структур данных к уровню абстракции данных
может служить класс строк из $$7.6. Здесь за счет инкапсуляции
символьных строк и стандартных строковых функций С
получается новый строковый тип, который гораздо проще использовать.
Подобным образом можно включить в иерархию классов любой
встроенный или отдельно определенный тип. Например, тип int
можно включить в иерархию классов так:
class Int : public My_object {
int i;
public:
// definition of operations
// see exercises [8]-[11] in section 7.14 for ideas
// определения операций получаются в упражнениях [8]-[11]
// за идеями обратитесь к разделу 7.14
};
Так следует делать, если действительно есть потребность
включить такие типы в иерархию.
Обратно, классы С++ можно представить в программе на С или
Фортране как функции и структуры данных. Например:
class myclass {
// representation
public:
void f();
T1 g(T2);
// ...
};
extern "C" { // map myclass into C callable functions:
void myclass_f(myclass* p) { p->f(); }
T1 myclass_g(myclass* p, T2 a) { return p->g(a); }
// ...
};
В С-программе следует определить эти функции в заголовочном файле
следующим образом:
// in C header file
extern void myclass_f(struct myclass*);
extern T1 myclass_g(struct myclass*, T2);
Такой подход позволяет разработчику на С++, если у него уже есть
запас программ, написанных на языках, в которых отсутствуют понятия
абстракции данных и иерархии классов, постепенно приобщаться к этим
понятиям, даже при том требовании, что окончательную версии программы
можно будет вызывать из традиционных процедурных языков.
Основное положение объектно-ориентированного проектирования и
программирования заключается в том, что программа служит моделью
некоторых понятий реальности. Классы в программе представляют
основные понятия области приложения и, в частности, основные
понятия самого процесса моделирования реальности. Объекты классов
представляют предметы реального мира и продукты процесса
реализации.
Мы рассмотрим структуру программы с точки зрения следующих
взаимоотношений между классами:
- отношения наследования,
- отношения принадлежности,
- отношения использования и
- запрограммированные отношения.
При рассмотрении этих отношений неявно предполагается, что их анализ
является узловым моментом в проекте системы. В $$12.4 исследуются
свойства, которые делают класс и его интерфейс полезными для
представления понятий. Вообще говоря, в идеале, зависимость класса
от остального мира должна быть минимальна и четко определена, а
сам класс должен через интерфейс открывать лишь минимальный объем
информации для остального мира.
Подчеркнем, что класс в С++ является типом, поэтому сами классы
и взаимоотношения между ними обеспечены значительной поддержкой
со стороны транслятора и в общем случае поддаются статическому анализу.
По сути в системе бывают классы двух видов:
[1] классы, которые прямо отражают понятия области приложения,
т.е. понятия, которые использует конечный пользователь для
описания своих задач и возможных решений;
и
[2] классы, которые являются продуктом самой реализации, т.е.
отражают понятия, используемые разработчиками и программистами
для описания способов реализации.
Некоторые из классов, являющихся продуктами реализации, могут
представлять и понятия реального мира. Например, программные и
аппаратные ресурсы системы являются хорошими кандидатами
на роль классов, представляющих область приложения. Это отражает
тот факт, что систему можно рассматривать с нескольких точек
зрения, и то, что с одной является деталью реализации, с
другой может быть понятием области приложения. Хорошо
спроектированная система должна содержать классы, которые
дают возможность рассматривать систему с логически
разных точек зрения. Приведем пример:
[1] классы, представляющие пользовательские понятия (например,
легковые машины и грузовики),
[2] классы, представляющие обобщения пользовательских понятий
(движущиеся средства),
[3] классы, представляющие аппаратные ресурсы (например, класс
управления памятью),
[4] классы, представляющие системные ресурсы (например,
выходные потоки),
[5] классы, используемые для реализации других классов (например,
списки, очереди, блокировщики) и
[6] встроенные типы данных и структуры управления.
В больших системах очень трудно сохранять логическое разделение
типов различных классов и поддерживать такое разделение между
различными уровнями абстракции. В приведенном выше перечислении
представлены три уровня абстракции:
[1+2] представляет пользовательское отражение системы,
[3+4] представляет машину, на которой будет работать система,
[5+6] представляет низкоуровневое (со стороны языка программирования)
отражение реализации.
Чем больше система, тем большее число уровней абстракции необходимо
для ее описания, и тем труднее определять и поддерживать эти уровни
абстракции. Отметим, что таким уровням абстракции есть прямое
соответствие в природе и в различных построениях человеческого
интеллекта. Например, можно рассматривать дом как объект,
состоящий из
[1] атомов,
[2] молекул,
[3] досок и кирпичей,
[4] полов, потолков и стен;
[5] комнат.
Пока удается хранить раздельно представления этих уровней абстракции,
можно поддерживать целостное представление о доме. Однако, если
смешать их, возникнет бессмыслица. Например, предложение
"Мой дом состоит из нескольких тысяч фунтов углерода, некоторых
сложных полимеров, из 5000 кирпичей, двух ванных комнат и 13
потолков" - явно абсурдно. Из-за абстрактной природы
программ подобное утверждение о какой-либо сложной программной
системе далеко не всегда воспринимают как бессмыслицу.
В процессе проектирования выделение понятий из области приложения
в класс вовсе не является простой механической операцией. Обычно
эта задача требует большой проницательности. Заметим, что сами
понятия области приложения являются абстракциями. Например, в
природе не существуют "налогоплательщики", "монахи" или "сотрудники".
Эти понятия не что иное, как метки, которыми обозначают бедную
личность, чтобы классифицировать ее по отношению к некоторой
системе. Часто реальный или воображаемый мир (например, литература,
особенно фантастика) служат источником понятий, которые кардинально
преобразуются при переводе их в классы. Так, экран моего компьютера
(Маккинтош) совсем не походит на поверхность моего стола, хотя
компьютер создавался с целью реализовать понятие "настольный" Ь,