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).