Лекции (1129116), страница 18

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

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

Вполне естественно, что разумнее реализовать стек в динамической памяти (отсюда появляются Init и Destroy).

А в модуле реализации будет следующее:

TYPE STACK = POINTER TO StackRec;

StackRec = Record

…

END;

То есть StackRec – это уже инкапсулированная структура данных. И уже Init будет заниматься распределением правильного количества памяти (Destroy ее освобождать) – эти процедуры являются аналогами конструктора и деструктора, правда, с одним отличием – мы сами должны не забыть вызывать в нужных местах Init и Destroy. Никакого контроля нет.

В итоге мы имеем два недостатка:

• невозможность защитить отдельные поля типа данных, только весь тип целиком

• навязывается конкретный способ реализации АТД (программист, который не хотел использовать динамические структуры данных не мог воспользоваться преимуществами инкапсуляции)

Oberon

Интересно то, что Oberon, который является более простым языком, чем Modula-2, убирает оба этих недостатка. В нем соединены понятия модуля реализации и модуля определений в одном физическом модуле.

MODULE

TYPE Stack* = RECORD

body: array 50 of INTEGER;

top: INTEGER;

END;

При этом можно открывать из закрывать отдельные поля типа (с помощью указания “*”). В данном примере мы не экспортируем внутреннюю часть типа (body и top), а только имя типа. В модуле определений (заметим, что это не часть языка, а лишь документационная часть для справки программисту), который будет сгенерирован мы увидим:

TYPE Stack = RECORD END:

Также и для процедур/функций – указание «*» будет означать экспорт.

В Oberon применяется очень простое математическое понятие проекции: все, что мы пометим «*» будет являться проекцией оригинала в модуль определений. Более того в Oberon-2 появилось понятие переменной, доступной только на чтение:

VAR Done *-: BOOLEAN;

То есть мы не сможем изменить переменную Done (это удобно для информационных переменных, которые содержат, например, коды ошибок).

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

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

• потенциальная видимость (имена, которые доступны через квалификатор или уточнение, например, имена объектов из интерфейсной части модуля)

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

В Modula-2 потенциальная видимость может быть снята следующим образом:

FROM M IMPORT …;

Ada

С этой точки зрения в Ada схема существенно более сложная. В Ada, как мы уже говорили, есть пакеты:

package M is

…

end M;

- это спецификация пакета

package body M is

…

end M;

- это реализация пакета.

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

Рассмотрим инкапсуляцию. Схема здесь похожа на Modula-2, с тем различием, что физически спецификация и реализация пакета могут быть физически в одном файле (но могут быть и разделены). Единицией защиты в Ada также является целый тип – либо тип полностью открыт, либо полностью инкапсулирован (является АТД). Но синтаксис АТД в Ada существенно более мощный (и сложный). Откуда бралась ограниченность АТД в Modula-2? Прежде всего из-за того, что модули определения и и реализации физически разделены, а также слишком мало информации сообщается о типе в модуле определений.

В Ada, если мы хотим объявить закрытый тип данных (АТД, в Ada они называются private), то следует писать следующим образом:

type T is private;

- это похоже на Modula-2, но более многословно. Однако, в Ada мы еще должны в этой же спецификации (не реализации!), где-то ниже написать:

private

type T is … ;

…

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

Общий синтаксис такой:

package <имя> is

…

private

<определения приватных типов>

end <имя>;

В результате мы можем реализовывать любую структуру АТД, компилятор видит полностью структуру типа (провести распределение памяти, оптимизации), поэтому сразу снимается ограничение, которое мы имеем в Modula-2. С другой стороны программист, который пишет клиентский модуль сможет увидеть структуру типа, но сделать с ней ничего не сможет – эта информация не для программиста.

Какие же недостатки в такой реализации (преимущества мы уже описали)? Прежде всего, любые исправления в модуле ведут к перекомпиляции клиентских модулей.

Какого рода операции можно применять к АТД? Как минимум: «присваивание», сравнение на «равенство»/«неравенство». Кроме того, за счет того, что компилятору доступна внутренняя структура АТД, мы получаем возможность сравнение на «больше», «меньше» (если эти операции определены над всеми полями типа).

Всегда ли хорош такой большой набор операций? Что из себя представляет оператор присваивания? В Modula-2 присваивание будет обозначать копирование значения указателя, если мы один стек присвоим другому, то получим два указателя на один стек. Если мы хотим копировать структуру, то должны писать отдельную процедуру.

В Ada, поскольку с указателями никаких проблем нет, то присваивание происходит побитово, в случае простых структур (стек), если же структура сложнее (динамическое дерево, например), то Ada предоставляет механизм запрета на операцию присваивания:

type T is limited private;

Limited означает, что все стандартные операции, указанные выше неприменимы к данному типу. Очевидно, что динамические структуры имеет смысл делать динамическими. Мы должны явно писать соответствующие процедуры.

В чем же сложность Ada? Сложность состоит в модели видимости данного языка. В чем проблемы? Набор модулей в Ada не есть линеечка (как в Modula-2 и Oberon), потому что простота модели видимости создавалась за счет равноправности модулей. В Ada же можно писать вложенные модули (пакеты). В результате, правила видимости существенно усложняются. Причем они оказались настолько сложными, что с момента утверждения стандарта Ada’83 не раз выпускались пояснения к стандарту, толкующие неявные места, и превышающие по объему описание стандарта языка…

<В этом месте следует описание модели видимости в Ada, по техническим причинам, не удалось полностью повторить описание представленное на лекции. /прим./ >

Все имена, определенные внутри M1 и M2 потенциально видимы и за пределами модуля M. Обращение к ним будет следовать, как M.M1.A или M.M2.E. На первый взгляд – ничего страшного. Немного похоже на блочную структуру языков программирования.

Но в Ada есть перекрытие имен и операций, предположим, у нас есть:

package Matricies is

type Matrix is private

…

function “+” (A, B: Matrix) return Matrix;

private type Matrix is

…

X,Y,Z: Matrix;

Z:=X+Y;

end;

Мы можем писать так: Z=X+Y;

А представим, что пакет Matricies куда-то вложен? Ведь «+» невидим вне модуля. Вот такое решение:

Z=Matricies.”+”(X,Y);

- смотрится не очень…

В Ada этот казус сняли следующим образом: ввели разрешение снимать потенциальную видимость:

Use <имена пакетов>;

После этого все имена пакетов становятся явно видимыми. Как только мы напишем:

Use Matricies;

Z=X+Y;

На первый взгляд все хорошо, но возникает проблема, если в модуле есть одинаковые имена. Правило такое: если два имени конфликтуют между собой, то они сразу оба невидны. Например, если модули M1 и M2 экспортируют имя Z, то после

Use M1, M2;

имя Z явно невидимо, к нему можно обращаться только через M1.Z, M2.Z.

А теперь представим, что Z – функция. Например, «+». Мы определим в M1 «+» для векторов, а в M2 – для матриц. И что же теперь закрывать «+»? Нет. В Ada для функций с одинаковыми именами разрешается видимость, если они имеют различные профили.

Но это только верхушка айсберга. Например, если у нас есть три модуля:

M1: в нем определена функция F;

M2: в нем определена также функция F, но с другим профилем;

M3: в нем определ тип F;

Тогда при написании:

Use M1, M2;

…

y=F(x);

…

z=F(x,y);

…

Use M3;

…

y=F(x) - ошибка!

…

Функции F перестанут быть видимыми сразу после написания Use M3.

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

Лекция 15

Инкапсуляция – это скрытие деталей реализации типа данных, для того, чтобы изолировать их от интерфейса типа данных. Абстрактные типы данных (АТД) – это максимальный случай инкапсуляции типов данных. АТД – это только множество операций (заданных, и возможно стандартных). К абстрактному типу данных можно обращаться только через четко описанное множество операций.

Рассмотрим подходы к инкапсуляции в классово ориентированных языках, таких как С++ и Java. В этих языках есть все возможные подходы, использованные в ранних языках. В этих языках детали реализации скрываются от доступа клиентов этого класса. До этого было только два вида доступа – публичный (public) и закрытый (private). С появлением наследования понадобился еще один вид доступа – защищенный (protected). Защищенные поля доступны только для функций-членов данного класса и для функций-членов класса-наследника.

Язык С++.

В классе С++ члены класса могут быть трех типов:

class X {

private: // доступно только для функций членов данного класса

int f();

…

public: // доступно для всех

int g();

…

protected: // доступно для наследников

int h();

…

}

Доступ к закрытым членам класса разрешается только из функций-членов данного класса (за исключением friend-классов, о которых будет сказано позднее). Обращение к членам класса не из данного класса осуществляется через операцию "точка": имя_класса.имя_объекта, и в этом смысле класс ведет себя точно также как модуль (вспомним МОДУЛУ-2, где обращение к члену модуля осуществляется аналогично). К статическим членам класса нужно обращаться иначе: имя_класса::имя_стат_члена.

В С++ класс проявляет двойственную природу – с одной стороны, это модуль, а с другой стороны, это тип данных. В этом смысле, концепция класса очень привлекательна.

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

Правила управления доступом распространяются на все без исключения члены класса, в т.ч. к конструкторам и деструкторам. Отсюда вытекают некоторые интересные особенности языка С++, которыми программисты имеют право играть, и иногда делают это довольно успешно.

class X{

X(); // по умолчанию конструктор скрыт (private)

public:

static X* Make();

~X();

}

В данном примере, конструктор скрыт, и это означает, что к конструктору данного класса нельзя обращаться извне. Если мы где-то вне этого класса опишем переменную этого класса (а это обращение к конструктору), то компилятор выдаст сообщение об ошибке. То же самое относится и к деструкторам. Даже если есть публичный конструктор, но деструктор скрыт, то переменные этого класса нельзя размещать вне этого класса, потому что рано или поздно надо будет уничтожать объект, а это невозможно. Зачем же нужны объекты, на которые нельзя ссылаться извне данного класса? В некоторых случаях удобно сделать функцию (Make), которая занимается генерацией соответствующих объектов явно. Т.е. мы можем например потребовать, чтобы объекты данного класса размещались только в динамической памяти. Как это сделать?

X* px;

px = X::Make(); // функция отводит место в динамической памяти и возвращает указатель на объект

…

delete px;

В этом классе можно сделать и деструктор приватным (запретить использование delete вне класса), например, чтобы реализовать динамическую сборку мусора. А функция Make может сама реализовывать свой алгоритм распределения памяти. Хотя того же можно добиться и через перекрытие операторов new и delete. Кроме того, мы можем запретить копирование объектов данного класса, скрыв конструктор копирования (например, если мы хотим гарантировать, что каждый объект класса уникален). С++ требует, чтобы при описании конструктора копирования, мы описали и операцию присваивания, при этом ее можно сделать ее тоже приватной.

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

Имеют ли смысл типы данных, все члены которых являются приватными? На первый взгляд нет, однако на самом деле имеют. Дело в том, что в связи с такой схемой защиты возникают некоторые проблемы. Опишем эти проблемы на двух примерах.

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

Список файлов лекций