Б. Страуструп - Язык программирования С++ (1119446), страница 89
Текст из файла (страница 89)
Из-за абстрактной природыпрограмм подобное утверждение о какой-либо сложной программной системе далеко не всегдавоспринимают как бессмыслицу.В процессе проектирования выделение понятий из области приложения в класс вовсе не является315Бьерн Страуструп.Язык программирования С++простой механической операцией. Обычно эта задача требует большой проницательности. Заметим,что сами понятия области приложения являются абстракциями. Например, в природе не существуют"налогоплательщики", "монахи" или "сотрудники". Эти понятия не что иное, как метки, которымиобозначают бедную личность, чтобы классифицировать ее по отношению к некоторой системе.
Частореальный или воображаемый мир (например, литература, особенно фантастика) служат источникомпонятий, которые кардинально преобразуются при переводе их в классы. Так, экран моего компьютера(Маккинтош) совсем не походит на поверхность моего стола, хотя компьютер создавался с цельюреализовать понятие "настольный", а окна на моем дисплее имеют самое отдаленное отношение кприспособлениям для презентации чертежей в моей комнате. Я бы не вынес такого беспорядка у себяна экране.Суть моделирования реальности не в покорном следовании тому, что мы видим, а в использованииреальности как начала для проектирования, источника вдохновения и как якоря, который удерживает,когда стихия программирования грозит лишить нас способности понимания своей собственнойпрограммы.Здесь полезно предостеречь: новичкам обычно трудно "находить" классы, но вскоре этопреодолевается без каких-либо неприятностей. Далее обычно приходит этап, когда классы и отношениянаследования между ними бесконтрольно множатся.
Здесь уже возникают проблемы, связанные сосложностью, эффективностью и ясностью полученной программы. Далеко не каждую отдельную детальследует представлять отдельным классом, и далеко не каждое отношение между классами следуетпредставлять как отношение наследования. Старайтесь не забывать, что цель проекта –смоделировать систему с подходящим уровнем детализации и подходящим уровнем абстракции. Длябольших систем найти компромисс между простотой и общностью далеко не простая задача.12.2.2 Иерархии классовРассмотрим моделирование транспортного потока в городе, цель которого достаточно точноопределить время, требующееся, чтобы аварийные движущиеся средства достигли пункта назначения.Очевидно, нам надо иметь представления легковых и грузовых машин, машин скорой помощи,всевозможных пожарных и полицейских машин, автобусов и т.п.
Поскольку всякое понятие реальногомира не существует изолированно, а соединено многочисленными связями с другими понятиями,возникает такое отношение как наследование. Не разобравшись в понятиях и их взаимных связях, мыне в состоянии постичь никакое отдельное понятие. Также и модель, если не отражает отношениямежду понятиями, не может адекватно представлять сами понятия.
Итак, в нашей программе нужныклассы для представления понятий, но этого недостаточно. Нам нужны способы представленияотношений между классами. Наследование является мощным способом прямого представленияиерархических отношений. В нашем примере, мы, по всей видимости, сочли бы аварийные средстваспециальными движущимися средствами и, помимо этого, выделили бы средства, представленныелегковыми и грузовыми машинами. Тогда иерархия классов приобрела бы такой вид:движущееся средстволегковая машинааварийное средствогрузовая машинаполицейская машинамашина скорой помощипожарная машинамашина с выдвижной лестницейЗдесь класс Emergency представляет всю информацию, необходимую для моделирования аварийныхдвижущихся средств, например: аварийная машина может нарушать некоторые правила движения, онаимеет приоритет на перекрестках, находится под контролем диспетчера и т.д.На С++ это можно задать так:classclassclassclassclassVehicle { /*...*/ };Emergency { /**/ };Car : public Vehicle { /*...*/ };Truck : public Vehicle { /*...*/ };Police_car : public Car , public Emergency {316Бьерн Страуструп.Язык программирования С++//...};class Ambulance : public Car , public Emergency {//...};class Fire_engine : public Truck , Emergency {//...};class Hook_and_ladder : public Fire_engine {//...};Наследование - это отношение самого высокого порядка, которое прямо представляется в С++ ииспользуется преимущественно на ранних этапах проектирования.
Часто возникает проблема выбора:использовать наследование для представления отношения или предпочесть ему принадлежность.Рассмотрим другое определение понятия аварийного средства: движущееся средство считаетсяаварийным, если оно несет соответствующий световой сигнал. Это позволит упростить иерархиюклассов, заменив класс Emergency на член класса Vehicle:движущееся средство (Vehicle {eptr})легковая машина (Car)грузовая машина (Truck)полицейская машина (Police_car)машина скорой помощи (Ambulance)пожарная машина (Fire_engine)машина с выдвижной лестницей (Hook_and_ladder)Теперь класс Emergency используется просто как член в тех классах, которые представляют аварийныедвижущиеся средства:classclassclassclassclassclassclassclassEmergency { /*...*/ };Vehicle { public: Emergency* eptr; /*...*/ };Car : public Vehicle { /*...*/ };Truck : public Vehicle { /*...*/ };Police_car : public Car { /*...*/ };Ambulance : public Car { /*...*/ };Fire_engine : public Truck { /*...*/ };Hook_and_ladder : public Fire_engine { /*...*/ };Здесь движущееся средство считается аварийным, если Vehicle::eptr не равно нулю.
"Простые"легковые и грузовые машины инициализируются Vehicle::eptr равным нулю, а для других Vehicle::eptrдолжно быть установлено в ненулевое значение, например:Car::Car(){eptr = 0;}Police_car::Police_car(){eptr = new Emergency;}// конструктор Car// конструктор Police_carТакие определения упрощают преобразование аварийного средства в обычное и наоборот:void f(Vehicle* p){delete p->eptr;p->eptr = 0;// больше нет аварийного движущегося средства//...p->eptr = new Emergency;// оно появилось снова}Так какой же вариант иерархии классов лучше? В общем случае ответ такой: "Лучшей является317Бьерн Страуструп.Язык программирования С++программа, которая наиболее непосредственно отражает реальный мир".
Иными словами, при выборемодели мы должны стремиться к большей ее"реальности", но с учетом неизбежных ограничений,накладываемых требованиями простоты и эффективности. Поэтому, несмотря на простотупреобразования обычного движущегося средства в аварийное, второе решение представляетсянепрактичным. Пожарные машины и машины скорой помощи – это движущиеся средства специальногоназначения со специально подготовленным персоналом, они действуют под управлением команддиспетчера, требующих специального оборудования для связи. Такое положение означает, чтопринадлежность к аварийным движущимся средствам - это базовое понятие, которое для улучшенияконтроля типов и применения различных программных средств должно быть прямо представлено впрограмме.
Если бы мы моделировали ситуацию, в которой назначение движущихся средств не стольопределенно, скажем, ситуацию, в которой частный транспорт периодически используется для доставкиспециального персонала к месту происшествия, а связь обеспечивается с помощью портативныхприемников, тогда мог бы оказаться подходящим и другой способ моделирования системы.Для тех, кто считает пример моделирования движения транспорта экзотичным, имеет смысл сказать,что в процессе проектирования почти постоянно возникает подобный выбор между наследованием ипринадлежностью. Аналогичный пример есть в $$12.2.5, где описывается свиток (scrollbar) прокручивание информации в окне.12.2.3 Зависимости в рамках иерархии классов.Естественно, производный класс зависит от своих базовых классов.
Гораздо реже учитывают, чтообратное также может быть справедливо.Эту мысль можно выразить таким способом: "Сумасшествие наследуется, вы можете получить его отсвоих детей."Если класс содержит виртуальную функцию, производные классы могут по своему усмотрению решать,реализовывать ли часть операций этой функции каждый раз, когда она переопределяется впроизводном классе. Если член базового класса сам вызывает одну из виртуальных функцийпроизводного класса, тогда реализация базового класса зависит от реализаций его производныхклассов.
Точно так же, если класс использует защищенный член, его реализация будет зависеть отпроизводных классов. Рассмотрим определения:class B {//...protected:int a;public:virtual int f();int g() { int x = f(); return x-a; }};Каков результат работы g()? Ответ существенно зависит от определения f() в некотором производномклассе. Ниже приводится вариант, при котором g() будет возвращать 1:class D1 : public B {int f() { return a+1; }};а при нижеследующем определении g() напечатает "Hello, World" и вернет 0:class D1 : public {int f() { cout<<"Hello, World\n"; return a; }};Этот пример демонстрирует один из важнейших моментов, связанных с виртуальными функциями.
Хотявы можете сказать, что это глупость, и программист никогда не напишет ничего подобного. Дело здесь втом, что виртуальная функция является частью интерфейса с базовым классом, и что этот класс будет,по всей видимости, использоваться без информации о его производных классах. Следовательно, можнотак описать поведение объекта базового класса, чтобы в дальнейшем писать программы, ничего незная о его производных классах.318Бьерн Страуструп.Язык программирования С++Всякий класс, который переопределяет производную функцию, должен реализовать вариант этойфункции.
Например, виртуальная функция rotate() из класса Shape вращает геометрическую фигуру, афункции rotate() для производных классов, таких, как Circle и Triangle, должны вращать объектысоответствующих типов, иначе будет нарушено основное положение о классе Shape. Но о поведениикласса B или его производных классов D1 и D2 не сформулировано никаких положений, поэтомуприведенный пример и кажется неразумным.
При построении класса главное внимание следуетуделять описанию ожидаемых действий виртуальных функций.Следует ли считать нормальной зависимость от неизвестных (возможно еще неопределенных)производных классов? Ответ, естественно, зависит от целей программиста. Если цель состоит в том,чтобы изолировать класс от всяких внешних влияний и, тем самым, доказать, что он ведет себяопределенным образом, то лучше избегать виртуальных функций и защищенных членов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
