Инварианты реализации
Инварианты реализации
Некоторые утверждения появляются в реализации, хотя они не имеют прямых двойников в спецификации АТД. Эти утверждения используют атрибуты, включая некоторые закрытые атрибуты, которые, по определению, не имеют смысла в АТД. Простым примером являются свойства, появляющиеся в инварианте STACK4:
count_non_negative: 0 <= count
count_bounded: count <= capacity
Такие утверждения составляют часть инварианта класса, известную как инвариант реализации (implementation invariant). Они позволяют задать соответствие представления реализации, выбранное в классе, (здесь это атрибуты count, capacity, representation) - визави соответствующего АТД.
Рис. 11.5 помогает понять концепцию инварианта реализации. Он иллюстрирует характеристические свойства функции абстракции, представленной вертикальной стрелкой на рисунке. Об этом стоит поговорить подробнее.
Прежде всего, корректно ли рассматривать а, как функцию? Напомним, что функция (тотальная или частичная) отображает каждый элемент исходного множества ровно в один элемент целевого множества, в противоположность общему случаю отношения, не имеющего такого ограничения. Рассмотрим обратное преобразование (сверху - вниз) от абстрактного объекта к конкретному. Будем называть его отношением представления (representation relation); как правило, это отношение не является функцией, так как существует множество представлений одного и того же абстрактного объекта. В реализации стека массивом, где каждый стек задан парой <representation, count>, абстрактный стек имеет много различных представлений, иллюстрируемых следующим рис. 11.6. Все они имеют одно и то же значение count и одинаковые элементы массива representation для всех индексов в пределах от 1 до count, но размер массивов - capacity - может быть любым значением, большим или равным count; элементы массива с индексом, большим count могут содержать произвольные значения.
Так как интерфейс класса ограничен компонентами, непосредственно выводимыми из функций АТД, клиенты не имеют способа различать поведение конкретных объектов, представляющих один и тот же абстрактный стек (это и есть причина, по которой все они имеют одну функцию абстракции a). Заметьте, в частности, что процедура remove из STACK4 выполняет свою работу, просто изменяя count
count := count - 1
не пытаясь очистить выше расположенные элементы. Всякое изменение элементов, расположенных выше count, будет модифицировать конкретный стек CS, не оказывая никакого влияния на ассоциированный абстрактный стек a(CS).
Итак, отношение реализации это обычно не функция. Но инверсия этого отношения - функция абстракции - действительно является функцией, так как каждому конкретному объекту ставится в соответствие один абстрактный объект. В примере стека каждой правильной паре <representation, count> соответствует в точности один абстрактный стек. У него count элементов, растет снизу вверх, элементы representation имеют индексы в пределах от 1 до count.
Рис. 11.6. Один абстрактный объект и два его представления
Оба конкретных стека, изображенные на рисунке, являются реализациями абстрактного стека, состоящего из трех элементов со значениями: 342, -133, 5. Отображение а должно быть функцией, иначе конкретный объект мог быть интерпретирован как реализация двух или более различных абстракций. В этом случае выбранная реализация двусмысленна и, следовательно, неадекватна. Поэтому стрелка, ассоциированная с а, правильно отображает существующую функциональную зависимость между абстрактными и конкретными типами. (Обсуждение наследования будет делаться при тех же предположениях).
Функция абстракции а обычно представима частичной функцией: не для каждого возможного конкретного объекта существует правильное представление абстрактного объекта. Например, не каждая пара <representation, count> является правильным представлением абстрактного стека. Если representation является массивом емкости 3 и count = 4, то они совместно не представляют абстрактный стек. Правильные представления (члены, входящие в область определения функции абстракции), - только те пары, для которых count находится между 0 и размерностью массива. Это свойство является инвариантом реализации.
В математических терминах, инвариант реализации является характеристической функцией области определения абстрактной функции. Другими словами, это булево свойство, определяющее применимость функции. (Характеристическая функция подмножества А задает булево свойство, истинное на А и ложное всюду вне его.)
Инвариант реализации является той частью утверждений класса, у которой нет двойника в спецификации АТД. Он не связан с АТД, и относится только к реализации. Он определяет, при каких условиях кандидат - конкретный объект - действительно является реализацией одного и только одного абстрактного объекта.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
Реализации процессора AS/400
Реализации процессора AS/400 Первые использовавшиеся в AS/400 RISC-процессоры поддерживали только режим активных тегов и только структуру ввода-вывода AS/400. Поэтому они выполняли приложения, но не операционные системы, написанные для стандартного процессора PowerPC. Любая другая
Стратегии реализации TCP
Стратегии реализации TCP Рассмотренный стандарт протокола TCP определяет взаимодействие между удаленными объектами, достаточное для обеспечения совместимых реализаций. Другими словами, модуль протокола, в точности следующий спецификации стандарта, является
15.1.4 Реализации NFS и RPC
15.1.4 Реализации NFS и RPC NFS и RPC были реализованы многими разработчиками систем Unix, а также перенесены во многие лицензированные операционные системы. Например, IBM VM, IBM MVS и DEC VAX VMS могут работать как файловые серверы NFS.Некоторые разработчики объединили программное
Реализации. NET
Реализации. NET В настоящий момент существует несколько реализаций того, что мы называем. NET.1. NET Framework – версия среды выполнения для серверных и настольных компьютеров с операционной системой Microsoft Windows. Она поставляется в составе операционных систем Windows XP Tablet Edition и Windows
От идеи к реализации
От идеи к реализации Перейдите от мозговых штурмов — к эскизам — к HTML — к кодированиюВот процесс Get Real, который мы используем:Мозговой штурмНачинайте с идеи. Что этот продукт собирается делать? Для Basecamp, мы смотрели на свои собственные потребности. Мы хотели сделать
5.3 Интерфейсы и Реализации
5.3 Интерфейсы и Реализации Что представляет собой хороший класс? Нечто, имеющее нбольшое и хорошо определенное множество действий. Нечто, что можно рассматривать как «черный ящик», которым манипулируют только посредством этого множества действий. Нечто, чье фатическое
5.3.1 Альтернативные Реализации
5.3.1 Альтернативные Реализации Пока описание открытой части класса и описание функций членов остаются неизменными, реализацию класса можно модифцировать не влияя на ее пользователей. Как пример этого расмотрим таблицу имен, которая использовалась в настольном
Различные реализации
Различные реализации Чтобы лучше понять всю важность описаний абстрактных типов данных, исследуем глубже потенциальные последствия использования физической реализации в качестве основы описания объектов.Удобным и хорошо изученным примером является описание
Инварианты класса
Инварианты класса Предусловия и постусловия описывают свойства отдельных программ. Но экземпляры класса обладают также глобальными свойствами. Их принято называть инвариантами класса (class invariants), и они определяют более глубокие семантические свойства и ограничения
Инварианты и контракты
Инварианты и контракты В метафоре контрактов интерпретация инвариантов ясна и понятна. В сообществе людей все контракты часто содержат ссылки на общие правила, регулирующие отношения между партнерами независимо от конкретной области применения контракта. Например
Инварианты и варианты цикла
Инварианты и варианты цикла Наши следующие и последние конструкции утверждений помогут строить корректные циклы. Эти конструкции являются прекрасным дополнением рассмотренных ранее механизмов. Поскольку они не являются специфической частью ОО-метода, то вы вправе
Инварианты класса и семантика ссылок
Инварианты класса и семантика ссылок ОО-модель, разрабатываемая до сих пор, включала два частично не связанных аспекта, оба из которых полезны:[x]. Понятие инварианта класса, введенное в этой лекции.[x]. Гибкая модель периода выполнения, детально рассмотренная в начальных
У11.5 Инвариант реализации
У11.5 Инвариант реализации Напишите инвариант реализации для класса
Инварианты
Инварианты С правилом об инвариантах класса мы встречались и прежде:Правило родительских инвариантовИнварианты всех родителей применимы и к самому классу.Инварианты родителей добавляются к классу. Инварианты соединяются логической операцией and then. (Если у класса нет