Бьерн Страуструп (947334), страница 6

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

Поскольку данные есть единственная вещь, которую хотят скрывать,

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

информации, т.е. имен переменных, констант, функций и типов, которые тоже

могут быть локальными в модуле. Хотя С++ и не предназначался специально

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

модульности ($$5.4.3 и $$5.4.4). Помимо этого С++, естественно, имеет уже

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

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

1.2.3 Абстракция данных

Модульное программирование предполагает группировку всех данных одного

типа вокруг одного модуля, управляющего этим типом. Если потребуются стеки

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

интерфейсом:

class stack_id { /* ... */ }; // stack_id только тип

// никакой информации о стеках

// здесь не содержится

stack_id create_stack ( int size ); // создать стек и возвратить

// его идентификатор

void push ( stack_id, char );

char pop ( stack_id );

destroy_stack ( stack_id ); // уничтожение стека

Конечно такое решение намного лучше, чем хаос, свойственный

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

типы совершенно очевидно отличаются от "настоящих", встроенных. Каждый

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

создания "переменных" этого типа. Не существует универсальных правил

присваивания идентификаторов, обозначающих объекты такого типа. У

"переменных" таких типов не существует имен, которые были бы известны

транслятору или другим системным программам, и эти "переменные" не

подчиняются обычным правилам областей видимости и передачи параметров.

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

существенно отличается от встроенных типов. Такие типы не получают той

поддержки со стороны транслятора (разного вида контроль), которая

обеспечивается для встроенных типов. Проблема здесь в том, что программа

формулируется в терминах небольших (одно-два слова) дескрипторов объектов,

а не в терминах самих объектов ( stack_id может служить примером такого

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

очевидные ошибки, вроде тех, что допущены в приведенной ниже функции:

void f ()

{

stack_id s1;

stack_id s2;

s1 = create_stack ( 200 );

// ошибка: забыли создать s2

push ( s1,'a' );

char c1 = pop ( s1 );

destroy_stack ( s2 ); // неприятная ошибка

// ошибка: забыли уничтожить s1

s1 = s2; // это присваивание является по сути

// присваиванием указателей,

// но здесь s2 используется после уничтожения

}

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

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

способствует ему.

В языках Ада, Clu, С++ и подобных им эта трудность преодолевается

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

трактуются в языке практически так же, как встроенные. Такие типы обычно

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

просто пользовательскими. Более строгим определением абстрактных типов

данных было бы их математическое определение. Если бы удалось его дать,

то, что мы называем в программировании типами, было бы конкретным

представлением действительно абстрактных сущностей. Как определить "более

абстрактные" типы, показано в $$4.6. Парадигму же программирования можно

выразить теперь так:

Определите, какие типы вам нужны; предоставьте полный набор операций

для каждого типа.

Если нет необходимости в разных объектах одного типа, то стиль

программирования, суть которого сводится к упрятыванию данных, и

следование которому обеспечивается с помощью концепции модульности, вполне

адекватен этой парадигме.

Арифметические типы, подобные типам рациональных и комплексных чисел,

являются типичными примерами пользовательских типов:

class complex

{

double re, im;

public:

complex(double r, double i) { re=r; im=i; }

complex(double r) // преобразование float->complex

{ re=r; im=0; }

friend complex operator+(complex, complex);

friend complex operator-(complex, complex); // вычитание

friend complex operator-(complex) // унарный минус

friend complex operator*(complex, complex);

friend complex operator/(complex, complex);

// ...

};

Описание класса (т.е. определяемого пользователем типа) complex задает

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

Представление является частным (private): re и im доступны только для

функций, указанных в описании класса complex. Подобные функции могут быть

определены так:

complex operator + ( complex a1, complex a2 )

{

return complex ( a1.re + a2.re, a1.im + a2.im );

}

и использоваться следующим образом:

void f ()

{

complex a = 2.3;

complex b = 1 / a;

complex c = a + b * complex ( 1, 2.3 );

// ...

c = - ( a / b ) + 2;

}

Большинство модулей (хотя и не все) лучше определять как

пользовательские типы.

1.2.4 Пределы абстракции данных

Абстрактный тип данных определяется как некий "черный ящик". После

своего определения он по сути никак не взаимодействует с программой. Его

никак нельзя приспособить для новых целей, не меняя определения. В этом

смысле это негибкое решение. Пусть, например, нужно определить для

графической системы тип shape (фигура). Пока считаем, что в системе могут

быть такие фигуры: окружность (circle), треугольник (triangle) и квадрат

(square). Пусть уже есть определения точки и цвета:

class point { /* ... */ };

class color { /* ... */ };

Тип shape можно определить следующим образом:

enum kind { circle, triangle, square };

class shape

{

point center;

color col;

kind k;

// представление фигуры

public:

point where () { return center; }

void move ( point to ) { center = to; draw (); }

void draw ();

void rotate ( int );

// еще некоторые операции

};

"Поле типа" k необходимо для того, чтобы такие операции, как draw () и

rotate (), могли определять, с какой фигурой они имеют дело (в языках

вроде Паскаля можно использовать для этого запись с вариантами, в которой

k является полем-дескриминантом). Функцию draw () можно определить так:

void shape :: draw ()

{

switch ( k )

{

case circle:

// рисование окружности

break;

case triangle:

// рисование треугольника

break;

case square:

// рисование квадрата

break;

}

}

Это не функция, а кошмар. В ней нужно учесть все возможные фигуры,

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

в системе появляется новая фигура. Плохо то, что после определения новой

фигуры нужно проверить и, возможно, изменить все старые операции класса.

Поэтому, если вам недоступен исходный текст каждой операции класса, ввести

новую фигуру в систему просто невозможно. Появление любой новой фигуры

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

Требуется достаточно высокая квалификация, чтобы справиться с этой

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

программы, работающих со старыми фигурами. Возможность выбора

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

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

общим определением фигуры (т.е. определением типа shape).

1.2.5 Объектно-ориентированное программирование

Проблема состоит в том, что мы не различаем общие свойства фигур

(например, фигура имеет цвет, ее можно нарисовать и т.д.) и свойства

конкретной фигуры (например, окружность - это такая фигура, которая имеет

радиус, она изображается с помощью функции, рисующей дуги и т.д.). Суть

объектно-ориентированного программирования в том, что оно позволяет

выражать эти различия и использует их. Язык, который имеет конструкции для

выражения и использования подобных различий, поддерживает

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

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

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

свойства всех фигур:

class shape

{

point center;

color col;

// ...

public:

point where () { return center; }

void move ( point to ) { center = to; draw(); }

virtual void draw ();

virtual void rotate ( int );

// ...

};

Те функции, для которых можно определить заявленный интерфейс, но

реализация которых (т.е. тело с операторной частью) возможна только для

конкретных фигур, отмечены служебным словом virtual (виртуальные). В

Симуле и С++ виртуальность функции означает: "функция может быть

определена позднее в классе, производном от данного". С учетом такого

определения класса можно написать общие функции, работающие с фигурами:

void rotate_all ( shape v [], int size, int angle )

// повернуть все элементы массива "v" размера "size"

// на угол равный "angle"

{

int i = 0;

while ( i<size )

{

v [ i ] . rotate ( angle );

i = i + 1;

}

}

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

это - именно фигура и задать ее особые свойства (включая и виртуальные

функции):

class circle : public shape

{

int radius;

public:

void draw () { /* ... */ };

void rotate ( int ) {} // да, пока пустая функция

};

В языке С++ класс circle называется производным по отношению к классу

shape, а класс shape называется базовым для класса circle. Возможна

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

классов circle и shape соответственно. Теперь парадигма программирования

формулируется так:

Определите, какой класс вам необходим; предоставьте полный набор

операций для каждого класса; общность классов выразите явно с помощью

наследования.

Если общность между классами отсутствует, вполне достаточно абстракции

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

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

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

В некоторых областях, таких, например, как интерактивная графика, есть

широкий простор для объектно-ориентированного программирования. В других

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

вычисления над ними, трудно найти применение для более развитых стилей

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

объектно-ориентированное программирование, очевидно, избыточны.

Нахождение общности среди отдельных типов системы представляет собой

нетривиальный процесс. Степень такой общности зависит от способа

проектирования системы. В процессе проектирования выявление общности

классов должно быть постоянной целью. Она достигается двумя способами:

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

построении других, либо поиском похожих классов для выделения их общей

части в один базовый класс.

С попытками объяснить, что такое объектно-ориентированное

программирование, не используя конкретных конструкций языков

программирования, можно познакомиться в работах [2] и [6], приведенных в

списке литературы в главе 11.

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

программирования для процедурного программирования, для упрятывания

данных, абстракции данных и объектно-ориентированного программирования.

Теперь несколько подробнее опишем средства языка, хотя и не самые

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

данных и объектно-ориентированное программирование.

1.3 "Улучшенный С"

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

арифметические операции, выбирающие операторы и циклы. Помимо этого должны

быть предоставлены операции ввода- вывода. Базовые языковые средства С++

унаследовал от С (включая указатели), а операции ввода-вывода

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

реализуется с помощью механизма раздельной трансляции.

1.3.1 Программа и стандартный вывод

Самая маленькая программа на С++ выглядит так:

Характеристики

Список файлов книги