В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 18
Текст из файла (страница 18)
вызовем строку 14' (и еще не созданное нами тело для этой процедуры).
Однако пора вспомнить о принципиальной проблеме, которая, возможно, уже
давно мучает вдумчивого читателя. Ведь теперь не гарантирована целостность
сетей! Для того мы и скрывали "сеть" в теле пакета, чтобы пользователь не
мог написать, например,
сеть(33).связан.число := 7;
и нарушить тем самым дисциплину работы с сетью так, что последующее
выполнение процедуры
удалить (33);
(в которой есть цикл по массиву связей узла 33) может привести к
непредсказуемым последствиям.
Введя объявление (в), пользователь может нарушить целостность объекта
сеть1 оператором
сеть1(33).связан.число := 7;
Теперь читателю должна стать полностью понятной принципиальная важность
концепции регламентированного доступа к объектам класса "сети", упомянутой
при постановке задачи : нужно позволить пользователю создавать новые сети и
работать с ними посредством объявленных операций, но нужно защитить сети от
нежелательного (несанкционированного) доступа. Обратите внимание: раньше
нежелательный доступ к объекту "сеть" был невозможен потому, что объект был
невидим пользователю, скрыт в теле пакета. Объявив тип "сети" в
спецификации, мы сделали видимыми для пользователя и имя типа, и имена
(селекторы) полей объектов этого типа.
Итак, основное противоречие в том, что скрыть объявление типа "сети" в
теле пакета нельзя - ведь нужно оставить видимым пользователю (чтобы он мог
объявлять новые сети), а оставить это объявление полностью открытым также
нельзя - пользователь может нарушить целостность сетей.
Вот если бы ввести тип так, чтобы его имя было видимо, а строение
объектов - невидимо (т.е. разделить его спецификацию и реализацию)! Тогда
технологическая потребность в регламентированном доступе была бы полностью
удовлетворена.
Эта красивая и естественная идея в Аде воплощена в концепции ПРИВАТНЫХ
типов данных (в Модуле-2 - в концепции так называемых "непрозрачных" типов
данных).
4.3.2. Приватные типы данных
Подумаем о выразительных средствах, реализующих концепцию
регламентированного доступа к данным определенного типа.
По существу нужно определить некоторую абстракцию данных - проявить то,
что существенно (для пользователя - имя типа и операции с объектами этого
типа) и скрыть то, что несущественно (и даже вредно знать пользователю -
строение объектов). Но ведь аналогичная задача для операционных абстракций
решается легко: в спецификацию пакета помещается то, что должно быть видимым
(спецификация операции), а в тело - то, что следует скрыть (полное
определение операции).
Так что было бы естественным аналогично оформить абстракцию данных -
поместить в спецификацию пакета то, что должно быть видимым (что может
играть роль минимальной "спецификации типа"), а в тело пакета упрятать
полное определение типа. В Аде минимальная "спецификация типа" воплощена
конструктом "объявление приватного типа", например
(а') type сети is private ;
(а также перечнем спецификаций применимых операций).
Полное определение приватного типа, по аналогии с определениями
операций, кажется естественным поместить в тело пакета. (Именно так сделано
в Модуле-2).
Почти так и нужно поступать в Аде. Но полное объявление приватного типа
приходится помещать не в тело пакета, а в "полузакрытую" (ПРИВАТНУЮ) часть
спецификации пакета, отделяемую от открытой части ключевым словом private.
Спецификация обновленного пакета, который назовем "управление_сетями",
может выглядеть следующим образом.
package управление_сетями is
... -- как и раньше; строки 2-11.
type сети is private ;
... -- операции над сетями
... -- строки 13-18.
... -- строки 13'-18'.
private
type запись_об_узле is
record
включен : bollean := false ;
связан : связи ;
end record ;
type сети is array (узел) of запись_об_узле ;
end управление_сетями ;
В общем случае спецификация пакета имеет вид
package имя_пакета is
объявления_видимой_части
[ private
объявления_приватной_части ]
end имя_пакета ;
Квадратные скобки указывают, что приватной части может и не быть (как,
например, в пакете управление_сетью).
Зачем же в Аде понадобилась приватная часть? Почему нет полной аналогии
между операционными абстракциями и абстракцией данных? (В языке Модула-2
эта аналогия выдержана полностью). На эти вопросы ответим позже.
Семантика приватной части проста. Эту часть можно считать "резидентом
тела пакета" в его спецификации. В теле пакета непосредственно доступны все
имена, объявленные в спецификации пакета, в том числе и в приватной части. С
другой стороны, в использующих этот пакет сегментах видимы только объявления
открытой части спецификации.
Напишем один из таких использующих сегментов - процедуру две_сети:
with управление_сетями ; use управление_сетями ;
procedure две_сети is
сеть1, сеть2 : сети ;
begin
вставить (13, в_сеть => сеть1 ) ;
вставить (33, в_сеть => сеть1 ) ;
связать (13, 33, в_сети => сеть1) ;
сеть2 := сеть1 ; -- присваивание полных объектов !
...
end две_сети ;
Когда управление дойдет до места, отмеченного многоточием, будут
созданы две сети: "сеть1" и "сеть2", с узлами 33 и 13, причем эти узлы
окажутся связанными между собой.
Таким образом, пользователи могут создавать сети и работать с ними с
полной гарантией целостности - все требуемые услуги предоставлены нашим
обновленным пакетом. Конечно, для этого нужно дополнить тело пакета,
поместив туда определения новых операций. Оставим это в качестве упражнения.
Вопрос. Нельзя ли испортить сеть за счет того, что доступен тип
"связи"? Ведь становятся известной структура связей указанного узла.
Подсказка. А где средства для несанкционированного изменения этой
структуры?
Итак, концепция регламентированного доступа в Аде воплощена разделением
спецификации и реализации услуг (разделением спецификации и тела пакета), а
также приватными типами данных.
Доступ к "приватным" данным возможен лишь посредством операций,
объявленных в ОПРЕДЕЛЯЮЩЕМ ПАКЕТЕ. Для любого определяемого типа данных (не
только приватного) так называется пакет, где расположено объявление этого
типа данных (для типов "сети", "узел", "связи" и др. таковым служит пакет
управление_сетями). Невозможен доступ, основанный на знании строения
объектов (т.е. выборкой или индексацией) - это строение скрыто в приватной
части и в использующих сегментах неизвестно.
Подчеркнем, что в теле определяющего пакета объекты приватных типов
ничем не отличаются от любых других - их строение известно, выборка и
индексация разрешены!
4.3.3. Строго регламентированный доступ. Ограниченные приватные
типы
В общем случае к объектам приватных типов применимы также операции
присваивания и сравнения на равенство и неравенство (полных объектов, как в
процедуре две_сети!). Хотя это и удобно (такие операции часто нужны и
неразумно заставлять программистов определять их для каждого приватного
типа), все-таки концепция строго регламентированного доступа в таких типах
не выдержана до конца. В Аде она точно воплощена лишь в так называемых
ОГРАНИЧЕННЫХ приватных типах. К объектам таких типов неприменимы никакие
предопределенные операции, в том числе присваивания и сравнения - все нужно
явно определять (в определяющем пакете). Объявления ограниченных приватных
типов выделяются ключевыми словами limited private , например
type ключ is limited private ;
Применение к объектам типа "ключ" операций присваивания или сравнения
вызовет сообщение об ошибке, если только в определяющем пакете для этого
типа не определены свои собственные операции, обозначаемые через ":=", "="
или "/=".
Так как ограниченные приватные типы точно воплощают идею строго
регламентированного доступа, интересно понять, в каких же задачах столь
строгие ограничения могут быть существенными.
Присваивания. Мы уже упоминали, что бывают ЯП вовсе без присваивания.
Таковы чистый Лисп, Базисный Рефал, функциональные и реляционные языки.
Подробнее поговорим о них позже. Чтобы соответствовать роли базового языка,
Ада должна предоставлять средства развития, позволяющие моделировать и такие
ЯП, причем моделировать в точности, с гарантией защиты создаваемых
абстракций. Так что ограниченные приватные типы вместе со средством их
определения (пакетом) - важнейшее средство развития в современном базовом
ЯП.
Упражнение (повышенной сложности). Создайте определяющий пакет для
каждой из рассмотренных далее моделей ЯП.
Замечание (о наблюдении Дейкстры). Подтверждением принципа цельности
(согласованности данных, операций, связывания) служит наблюдение Дейкстры,
что присваивание нужно лишь в тех языках, где есть повторения (циклы).
Именно в циклах появляются переменные, которым нужно присваивать значения
(постоянные относительно очередного исполнения тела цикла).
Когда циклов нет и потенциальная бесконечность обслуживается рекурсией
(в Лиспе, Рефале, и т.п.), достаточна ИНИЦИАЛИЗАЦИЯ (частный случай
присваивания - присваивание начальных значений). Так что наличие циклов
должно быть согласовано не только с другими операциями (присваиванием), но и
с данными (появляются переменные), а также со связыванием (областью действия
каждой переменной в таких ЯП в идеале должен быть некоторый цикл).
Вопрос. Что можно сказать в этих условиях об исходных данных и
результатах?
Рассмотрим пример. Допустим, что нужно моделировать выпуск изделий с
уникальными номерами (вспомним заводские номера двигателей, автомобилей,
самолетов и т.п.). Естественно считать, что объект приватного типа "изделие"
- результат базовой для этого типа функции "создать", генерирующей очередное
"изделие". Если позволить присваивать объекты этого типа переменным, то
станет возможным их дублировать и уникальность будет нарушена. Поэтому тип
"изделие" должен быть ограниченным приватным.
Сравнения. Во-первых, эти операции для объектов некоторых типов могут
попросту не иметь смысла, т.е. объекты могут быть несравнимыми. Из
соображений надежности попытку их сравнения следует квалифицировать как
ошибку (т.е. сравнение должно быть запрещено). Так, при первоначальном
знакомстве с Адой упоминались задачные типы, объекты которых - параллельно
исполняемые задачи. Сравнение таких объектов на равенство (при отсутствии
присваивания) бессмысленно просто потому, что любой из них уникален по
определению. Да и содержательно трудно приписать какой либо естественный
смысл сравнению на равенство (а не, например, на подобие) двух независимо
исполняемых задач. Ведь они в постоянном изменении, причем асинхронном, а
всякое реальное сравнение занимает время.
Поэтому в Аде задачные типы - ограниченные приватные по определению и,
следовательно, всякая попытка сравнить задачи на равенство квалифицируется
как ошибка. Кстати, любые составные типы с компонентами ограниченного типа
считаются ограниченными.
Во-вторых, нежелание допускать сравнение на равенство может быть
связано с защитой от нежелательного доступа, с обеспечением секретности.
Так, и пользователи, и файлы в файловой системе могут быыть снабжены
атрибутами типа "ключ". Однако неразумно разрешать пользователю сравнивать
ключи, чтобы решать, пользоваться файлом или нет. Право сравнивать ключи и
разрешать доступ должно быть только у самой файловой системы. Поэтому для
пользователя тип "ключ" должен быть ограниченным - он может его передать
другому, но не может "подделать" или "подобрать".
4.3.4. Инкапсуляция
Определение приватных типов данных - один из примеров инкапсуляции -
заключения в "защитную оболочку", предохраняющую от разрушения. Мы видели,
как недоступность (защита) строения объектов приватных типов от
произвольного доступа со стороны пользователя гарантирует их целостность в
некотором содержательном смысле.
Понятие инкапсуляции по общности занимает промежуточное положение между
концепцией регламентированного доступа и ее конкретной реализацией
приватными типами данных.
Приватные типы Ады с точки зрения пользователя - это инкапсулированные
(защищенные) типы данных. Однако с точки зрения реализатора тела
определяющего пакета - это обычные незащищенные типы. В общем случае
инкапсулировать можно не только типы, но и отдельные объекты или системы
объектов (таковы объекты, объявленные в теле пакета).
Итак, задача о моделировании сетей помогла проявить технологическую
потребность в инкапсуляции и дала повод поработать с конструктами,
удовлетворяющими эту потребность - с объявлениями приватного типа и
пакетами.
4.4. Характеристики, связанные с типом. Класс значений, базовый набор
операций
Продолжим анализ общей концепции типа данных. До сих пор мы
концентрировали внимание только на способе привязки характеристик к объектам
данных. Сутью характеристик мы при этом не интересовались. Перед нами
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
