Лекция 13 (лекции (2002)), страница 2

try {

«захват ресурса»

} finally { «освобождение» }

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

{ C x

захват ресурса

} деструктор освобождает ресурс

В языках, где нет неявного вызова деструктора (C#, Delphi, Java) работа с ресурсами организуется через эти try-блоки, так как полагаться на деструкторы мы уже не можем. Блок finally выполнится всегда, как бы не закончился try (нормальным образом выйдя через скобку или через return или ненормальным образом, если произошла какая-то аварийная ситуация). И область метода finalize ограничена.

С#: вообще-то есть деструкторы, но это на самом деле финализаторы. И совет: делать метод close и использовать его явно. Например, с помощью конструкции try … finally.

Delphi:

try

...

finally

...

end.

Глава 6. Инкапсуляция. Абстрактные типы данных.

{На госэкзамен из курса Языков Программирования выносятся только два вопроса ООЯП и данная глава}

Инкапсуляция данных- упрятывание или сокрытие данных (операций), то есть доступ со стороны пользователя к ним сокрыт. Это то самое свойство, которое подразумевают в первую очередь, когда говорят о свойствах языка, делающих его объектно ориентированным (а также классические: наследование и динамический полиморфизм).

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

Абстрактный ТД (АТД) - что это? Абстрактный класс (АК) в ООЯ ≠ АТД. И их не следует путать. Хотя и существуют АК, которые являются АТД, но так же есть АК, которые не являются АТД (во-первых термин АК применим только для ООЯП, где есть наследование или виртуальные методы, а АТД это взглад на ТД только с точки зрения инкапсуляции, то есть это понятия ортоганальные) и АТД, которые.не являются АК.

АТД- это ТД, где множество операций- только множество операций, которые задаёт пользователь. И мы можен работать с ним только в терминах множества операций, которые задаёт пользователь. С точки зрения пользователя: АТД ≡ множество операций, которые явно определит пользователь. И он не зависит от реализации. И в этом его главное достоинсво. Поэтому концепция АТД, которая появилась в 70-е годы в связи с развитием модульных ЯП, перешла во все современные ЯП.

Мы тут сталкнулись с ситуацией, с которой сталкнулись программисты в конце 60-х годов, когда развивалась дисциплина структурного (или структурированного) программирования- это добровольный отказ от некоторых средств записи кода (неограниченный оператор goto, ограничение выразительных возможностей структурами, имеющими один вход и один выход). Выразительность ЯП падает, но на практиче сокращается время на написание программ, программы легче писать, понимать и, следовательно, сопровождать. Инкапсуляция- это запрет пользователю ТД ссылаться на некоторые операции и, вообще, на множество значений, в случае АТД. Оказывается, что этот запрет благотворно влияет на пользователя. Например ТД стек, где мы не можем иметь произвольный доступ к структуре данных. У него есть указатель на первый свободный элемент в этом массиве: top и пользователя не в коем случае нельзя допускать к произвольной работе с ним, лучше её вообще скрыть, так как изменение её значения приводит к нарушению целостности структуры данных. Благодаря этому программист-пользователь ориентируется на базовые свойства ТД, не отвлекаясь на реализацию. А когда программист начинает разбираться в реализации? Вот три вырожденных случая:

1)недостаток документации (не понятно, как работают те или иные операции ТД)

2)есть ошибки (в реализации ТД)

3)хочет эффективнее

И если ТД спроектирован хорошо, то этих случаев не возникает. Поэтому инкапсуляция- это благо и она реализована во всех ЯП.

Модульные ЯП

Инкапсуляцию иногда называют защита данных, но возникает вопрос: «от кого?». Инкапсуляция- защита данных от дурака, а не от злоумышленника. Почти везде можно легко взломать защиту (получить доступ к данным), ну разве, что в Jave приложили серьёзные усилия, чтобы не позволить программисту снимать эту защиту. В С++ можно использовать указатели и неконтроллируемые их преобразования. Мы знаем реализацию методов ТД и расположение данных в памяти: указатель на ТД с той же структурой, но публичной приводим к указателю на необходимый объект и тем самым получаем полный доступ к нему. То есть просто у пользователя нет возможности сломать структуру данных (объект), а когда делаем что-то не правильно (пытаемся забрать что-то из пустого стека), то получаем исключительную ситуацию. Например, при хорошей защите пользователь не может сломать стек (нарушить его целостность).

Единица защиты:

1)Тип целиком – выбирают все ЯП, которые мы рассматриваем.

2)Отдельные переменные (экземпляры) [разные стратегии защиты для разных объектов одного типа]

Атом защиты:

1)Вся структура данных – Модула-2, Ада

2)Отдельные члены (более гибко) – Оберон, Delphi, Java, C#, C++

Модула-2 и Ада призывают писать в терминах АТД, так как это хорошо. В них составной ТД (то есть реализуется, как правило, на базе записи) либо целиком открыт, либо целиком закрыт.

Модула-2: либо вся структура закрыта, либо открыта.

DEFINITION MODULE M;

TYPE T =

RECORD

... /* описание членов */

END;

операции

END M;

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

АТД:

...

TYPE T; /* скрытый ТД (opaque) */

операции над Т; /* про реализацию не известно, над ним можем делать только эти операции */

CONST N; /* означает, что значение этой константы заранее не известно */

END M;

Конкретная структура ТД должна раскрываться, соответственно, в реализации.

IMPLEMENTATION MODULE M

...

END M;

О скрытом ТД в Модуле-2 нам известно только его имя и ничего о его структуре не известно.

Отсюда возникает ограничение: скрытый ТД, с точки зрения реализации, может выглядеть либо как указатель, либо как ТД, совместимый с указателем по памяти (то есть целый – INT). И следующая запись будет ошибочной:

TYPE T = RECORD …

Пример, модуль:

InOut

Где есть, скрытый ТД “файл”:

FileStream

Это INT– аналог файлового дескриптора, то есть где-то в модуле реализации отведён массив структур данных под эти файлы и его размер определяет число файлов, открытых одновременно. И этот ТД “файл”- это индекс соответствующей структуры данных в этом массиве. Но чаще ТД- это указатель на некоторую запись. Но мы вынуждены организовывать всю работу через динамическую память, то есть у нас обязаны быть операции:

Init(VAR X : T);

Destroy(X : T);

Следовательно мы получаем проблему конструирования и разрушения (автоматически не разрешенную в Модуле-2). Пользователь должен не забывать по Init и Destroy. В случае файлов это будет: Open и Close.

Но откуда взялось такое неприятное ограничение? Из-за особенностей раздельной трансляции модулей с языка Модула-2: для компиляции нужны только модули определений (без модулей реализации). Вся необходимая информация для компилятора содержится в модуле определений. Пусть в модуле М описан скрытый тип данных

«TYPE T; »:

M1:

FROM M IMPORT T;

X : T;

Это модуль М1. При его компиляции надо знать размер типа Т. Компилятор видит только модуль определений от М, а там про Т написано только его имя. Отсюда и возникло ограничение на то, что Т- это указатель или тип совместимый по памяти с указателем и компилятор отводит память под тип данных INTEGER (точнее- под тип данных указатель).

Операции к скрытому ТД в Модуле-2: все, описанные в модуле определений, а так же все, которые можно выполнять над указателем или ссылкой: операции сравнения ссылок «=» (равно) и «#» (не равно- в Модуле-2 выглядит именно таким образом); «:=» - это поверхностное присваивание ( присваивание ссылок). С элементами скрытого ТД мы работаем в терминах ссылок на него (на его объекты). Но если хотим делать глубинное копирование, то надо делать:

PROCEDURE clone(X : T) : T;

VAR не надо, так как X- уже ссылка.

Если глубинное сравнение (сравнение по структурам данных):

PROCEDURE IsEqual(X1, X2 : T) : Boolean;

Достоинства:

1)Присутствует понятие АТД.

2)Простая реализация АТД, следовательно простой язык и простой компилятор (в описании Модулы-2 скрытым ТД посвящено полстранички).

Недостатки:

1)Для реализации используем одну и ту же схему- динамическую память

2)Работа происходит в терминах ссылок (но язык не поддерживает проблемы инициализации, копирования и сравнения на равенство/неравенство- все проблемы кладутся на программиста-пользователя).

Aда: другой подход- существует более глубокое понятие инкапсуляции. Здесь мы опять же либо целиком инкапсулируем весь ТД, либо целиком его открываем.

АТД: это либо приватный ТД:

private

либо ограниченный приватный ТД (некоторое обобщение приватного ТД):

limited private

private: похож на скрытый ТД в Модуле-2, программист о нём не знает ничего, кроме набора операций.

package M is type T is private;

операции над Т

Если бы мы здесь как в Модуле-2 поставили END, то сталкнулись бы с ситуацией, когда компилятор когда компилирует модуль М1, который импортирует модуль М, он должен для эффективности знать размер типа данных Т, и поэтому в Модуле-2 работать с элементами АТД можно было только через указатели. А здесь приватная часть, где описание всех приватных ТД (в Аде пакет может служить для определения многих ТД), где раскрывается их структура (и все подструктуры):

private

описание всех приватных ТД

type T is record ... size = 25; end record;

end M;

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

use M;

x : T; //компилятор, видя только спецификацию пакета, отведёт

//память и проинициализирует поле size.

Но писать x.size- нельзя, так как структура данных открыта компилятору, но закрыта для программиста пользователя. Плюс такого подхода: полная свобода с точки зрения реализации АТД (ничем не отличается от реализации обычных ТД). А недостаток: если меняем структуру пакета, где находится АТД, то надо перекомпилировать все модули, использующие этот АТД, в отличие от Модулы-2, где надо было перекомпилировать только модуль реализации. Накладные расходы на перекомпиляцию Но при современных мощностях это не существенно. Приватный ТД- это некое расширение скрытого ТД в Модуле-2.

Операции над приватным ТД: все, определённые в описании; «:=» - присваивание; и операции сравнения «=, /=, <=, <, >=»- в зависимости от структуры (компилятор её знает).

В Аде есть приятная особенность: к составным базисным ТД (запись, массив) применимы любые операции сравнения, если они применимы покомпонентно:

array (0 .. 10) of T0;

И если Т0, например, INTEGER, над которым применимы любые операции сравнения, следовательно над любыми массивами такого типа применимы все операции сравнения.

type T is array (range <>) of T1;

Если

X1 : T(0 .. 10);

X2 : T(1 .. 11);

X3 : T(-1 .. 21);

То (Х1, Х2) можно сравнивать, а (Х1, Х3) и (Х2, Х3)- нельзя.

record

a : T1;

b : T2;

end

Если к Т1 и Т2 применимы операции сравнения, то и ко всему типу данных запись они применимы.

Тоже самое относиться и к операции присваивания. И компилятор, зная структуру ТД понимает можно применять такие операции или нельзя.

Ограниченный приватный ТД (limited private). К нему применимы только базовые операции (определённые пользователем), а операции присваивания и сравнения применять нельзя (вне зависимости от структуры)- это полностью абстрактный ТД:

...

type T is limited private;

операции

private

...

type T is ...;

end M;

Применить операции присваивания и сравнения нельзя. В частности ограниченный приватный ТД удобен, когда нельзя просто так применять операцию присваивания указателей (когда в это ТД есть ссылки на другие ТД или динамические ссылки), то есть копировать нельзя, но можно clone (или copy)- настоящее копирование этого ТД. А если пользователь забудит про это и попробует применить операцию присваивания, то компилятор выдаст ему сообщение об ошибке. Эта концепция- настоящий АТД, значительно более абстрактный, чем скрытый ТД в Модуле-2 (он там и не назывался АТД).