Бьярн Страуструп - Язык программирования C++

Бьерн Страуструп. Язык программирования С++

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();

Обратите внимание, что сделав предположения k() о своих аргументах явными, мы переместили контроль ошибок с этапа выполнения на этап трансляции. Сложные примеры, подобные приведенному, возникают, когда пытаются реализовать на С++ проекты, сделанные на основе опыта работы с другими системами типов. Обычно это возможно, но в результате получается неестественная и неэффективная программа. Такое несовпадение между приемами проектирования и языком программирования можно сравнить с несовпадением при пословном переводе с одного естественного языка на другой. Ведь английский с немецкой грамматикой выглядит столь же неуклюже, как и немецкий с английской грамматикой, но оба языка могут быть доступны пониманию того, кто бегло говорит на одном из них.

Этот пример подтверждает тот вывод, что классы в программе являются конкретным воплощением понятий, используемых при проектировании, поэтому нечеткие отношения между классами приводят к нечеткости основных понятий проектирования.

12.1.4 Гибридный проект

Переход на новые методы работы может быть мучителен для любой организации. Раскол внутри нее и расхождения между сотрудниками могут быть значительными. Но резкий решительный переход, способный в одночасье превратить эффективных и квалифицированных сторонников "старой школы" в неэффективных новичков "новой школы" обычно неприемлем. В то же время, нельзя достичь больших высот без изменений, а значительные изменения обычно связаны с риском.

Язык С++ создавался с целью сократить такой риск за счет постепенного введения новых методов. Хотя очевидно, что наибольшие преимущества при использовании С++ достигаются за счет абстракции

312

данных, объектно-ориентированного программирования и объектно-ориентированного проектирования, совершенно неочевидно, что быстрее всего достичь этого можно решительным разрывом с прошлым. Вряд ли такой явный разрыв будет возможен, обычно стремление к усовершенствованиям сдерживается или должно сдерживаться, чтобы переход к ним был управляемым. Нужно учитывать следующее:

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

-Новые программы должны взаимодействовать со старыми программами.

-Старые программы нужно сопровождать (часто бесконечно).

-Работа по текущим проектам и программам должна быть выполнена в срок.

-Средства, рассчитанные на новые методы, нужно адаптировать к локальному окружению.

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

Поскольку в С++ возможны несколько схем программирования, язык допускает постепенный переход на него, используя следующие преимущества такого перехода:

-Изучая С++, программисты могут продолжать работать.

-В окружении, бедном на программные средства, использование С++ может принести значительные выгоды.

-Программы, написанные на С++, могут хорошо взаимодействовать с программами, написанными на С или других традиционных языках.

-Язык имеет большое подмножество, совместимое с С.

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

Идея постепенного, пошагового овладения С++, а также возможность смешивать программы на С++ с программами, написанными на языках, не имеющих средств абстракции данных и объектноориентированного программирования, естественно приводит к проекту, имеющему гибридный стиль. Большинство интерфейсов можно пока оставить на процедурном уровне, поскольку что-либо более сложное не принесет немедленного выигрыша. Например, обращение к стандартной библиотеке math из С определяется на С++ так:

extern "C" {

#include <math.h>

}

и стандартные математические функции из библиотеки можно использовать так же, как и в С. Для всех основных библиотек такое включение должно быть сделано теми, кто поставляет библиотеки, так что программист на С++ даже не будет знать, на каком языке реализована библиотечная функция. Использование библиотек, написанных на таких языках как С, является первым и вначале самым важным способом повторного использования на С++.

На следующем шаге, когда станут необходимы более сложные приемы, средства, реализованные на таких языках как С или Фортран, представляются в виде классов за счет инкапсуляции структур данных и функций в интерфейс классов С++. Простым примером введения более высокого семантического уровня за счет перехода от уровня процедур плюс структур данных к уровню абстракции данных может служить класс строк из $$7.6. Здесь за счет инкапсуляции символьных строк и стандартных строковых функций С получается новый строковый тип, который гораздо проще использовать.

Подобным образом можно включить в иерархию классов любой встроенный или отдельно определенный тип. Например, тип int можно включить в иерархию классов так:

class Int : public My_object {

313

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.2 Классы

Основное положение объектно-ориентированного проектирования и программирования заключается в том, что программа служит моделью некоторых понятий реальности. Классы в программе представляют основные понятия области приложения и, в частности, основные понятия самого процесса моделирования реальности. Объекты классов представляют предметы реального мира и продукты процесса реализации.

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

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

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

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

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

При рассмотрении этих отношений неявно предполагается, что их анализ является узловым моментом в проекте системы. В $$12.4 исследуются свойства, которые делают класс и его интерфейс полезными для представления понятий. Вообще говоря, в идеале, зависимость класса от остального мира должна быть минимальна и четко определена, а сам класс должен через интерфейс открывать лишь минимальный объем информации для остального мира.

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

314

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

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

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

[1] классы, которые прямо отражают понятия области приложения, т.е. понятия, которые использует конечный пользователь для описания своих задач и возможных решений; и

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

Некоторые из классов, являющихся продуктами реализации, могут представлять и понятия реального мира. Например, программные и аппаратные ресурсы системы являются хорошими кандидатами на роль классов, представляющих область приложения. Это отражает тот факт, что систему можно рассматривать с нескольких точек зрения, и то, что с одной является деталью реализации, с другой может быть понятием области приложения. Хорошо спроектированная система должна содержать классы, которые дают возможность рассматривать систему с логически разных точек зрения. Приведем пример:

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

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

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

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

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

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

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

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

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

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

Чем больше система, тем большее число уровней абстракции необходимо для ее описания, и тем труднее определять и поддерживать эти уровни абстракции. Отметим, что таким уровням абстракции есть прямое соответствие в природе и в различных построениях человеческого интеллекта. Например, можно рассматривать дом как объект, состоящий из

[1] атомов,

[2]молекул,

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

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

[5]комнат.

Пока удается хранить раздельно представления этих уровней абстракции, можно поддерживать целостное представление о доме. Однако, если смешать их, возникнет бессмыслица. Например, предложение "Мой дом состоит из нескольких тысяч фунтов углерода, некоторых сложных полимеров, из 5000 кирпичей, двух ванных комнат и 13 потолков" - явно абсурдно. Из-за абстрактной природы программ подобное утверждение о какой-либо сложной программной системе далеко не всегда воспринимают как бессмыслицу.

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

315

простой механической операцией. Обычно эта задача требует большой проницательности. Заметим, что сами понятия области приложения являются абстракциями. Например, в природе не существуют "налогоплательщики", "монахи" или "сотрудники". Эти понятия не что иное, как метки, которыми обозначают бедную личность, чтобы классифицировать ее по отношению к некоторой системе. Часто реальный или воображаемый мир (например, литература, особенно фантастика) служат источником понятий, которые кардинально преобразуются при переводе их в классы. Так, экран моего компьютера (Маккинтош) совсем не походит на поверхность моего стола, хотя компьютер создавался с целью реализовать понятие "настольный", а окна на моем дисплее имеют самое отдаленное отношение к приспособлениям для презентации чертежей в моей комнате. Я бы не вынес такого беспорядка у себя на экране.

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

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

12.2.2 Иерархии классов

Рассмотрим моделирование транспортного потока в городе, цель которого достаточно точно определить время, требующееся, чтобы аварийные движущиеся средства достигли пункта назначения. Очевидно, нам надо иметь представления легковых и грузовых машин, машин скорой помощи, всевозможных пожарных и полицейских машин, автобусов и т.п. Поскольку всякое понятие реального мира не существует изолированно, а соединено многочисленными связями с другими понятиями, возникает такое отношение как наследование. Не разобравшись в понятиях и их взаимных связях, мы не в состоянии постичь никакое отдельное понятие. Также и модель, если не отражает отношения между понятиями, не может адекватно представлять сами понятия. Итак, в нашей программе нужны классы для представления понятий, но этого недостаточно. Нам нужны способы представления отношений между классами. Наследование является мощным способом прямого представления иерархических отношений. В нашем примере, мы, по всей видимости, сочли бы аварийные средства специальными движущимися средствами и, помимо этого, выделили бы средства, представленные легковыми и грузовыми машинами. Тогда иерархия классов приобрела бы такой вид:

движущееся средство легковая машина аварийное средство грузовая машина полицейская машина машина скорой помощи пожарная машина

машина с выдвижной лестницей

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

На С++ это можно задать так:

class Vehicle { /*...*/ }; class Emergency { /* */ };

class Car : public Vehicle { /*...*/ }; class Truck : public Vehicle { /*...*/ };

class 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 используется просто как член в тех классах, которые представляют аварийные движущиеся средства:

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

Такие определения упрощают преобразование аварийного средства в обычное и наоборот:

void f(Vehicle* p)

{

}

Так какой же вариант иерархии классов лучше? В общем случае ответ такой: "Лучшей является

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 не сформулировано никаких положений, поэтому приведенный пример и кажется неразумным. При построении класса главное внимание следует уделять описанию ожидаемых действий виртуальных функций.

Следует ли считать нормальной зависимость от неизвестных (возможно еще неопределенных) производных классов? Ответ, естественно, зависит от целей программиста. Если цель состоит в том, чтобы изолировать класс от всяких внешних влияний и, тем самым, доказать, что он ведет себя определенным образом, то лучше избегать виртуальных функций и защищенных членов. Если цель состоит в том, чтобы разработать структуру, в которую последующие программисты (или вы сами через неделю) смогут встраивать свои программы, то именно виртуальные функции и предлагают элегантный способ решения, а защищенные члены могут быть полезны при его реализации.

В качестве примера рассмотрим простой шаблон типа, определяющий буфер:

template<class T> class buffer {

// ...

void put(T); T get();

};

Если реакция на переполнение и обращение к пустому буферу, "запаяна" в сам класс, его применение будет ограничено. Но если функции put() и get() обращаются к виртуальным функциям overflow() и underflow() соответственно, то пользователь может, удовлетворяя своим нуждам, создать буфера различных типов:

template<class T>

class circular_buffer : public buffer<T> {

//...

int overflow(T); // перейти на начало буфера, если он полон int underflow();

};

template<class T>

class expanding_buffer : public buffer<T> {

//...

int overflow(T); // увеличить размер буфера, если он полон int underflow();

};

Этот метод использовался в библиотеках потокового ввода-вывода ($$10.5.3).

12.2.4 Отношения принадлежности

Если используется отношение принадлежности, то существует два основных способа представления объекта класса X:

[1] Описать член типа X.

319