Основы объектно-ориентированного программирования

         

Класс стек


Этот пример даст возможность ознакомиться с практическим использованием утверждений. В предыдущей лекции была дана схема параметризованного класса "стек" в форме:

class STACK [G] feature ... Объявление компонент: count, empty, full, put, remove, item end

Реализация появится ниже. До рассмотрения проблем реализации важно отметить, что программы характеризуются строгими семантическими свойствами, не зависящими от специфики реализации. Например:

  • Программы remove и item применимы, только если число элементов стека не равно нулю.
  • put увеличивает, remove - уменьшает число элементов на единицу.

Такие свойства являются частью спецификации АТД, и даже люди далекие от использования любых формальных подходов неявно их понимают. Но в общих подходах к разработке ПО в программных текстах нельзя обнаружить следов спецификации. Предусловие и постусловие программы можно сделать явными элементами ПО. Так и поступим. Введем предусловие и постусловие как специальный вид объявлений с помощью ключевых слов require и ensure соответственно. Для класса "стек" это приведет к следующей записи, где временно оставлены пустые места для реализации:

indexing description: "Стеки: Структуры с политикой доступа Last-In, First-Out % %Последний пришел - Первый ушел" class STACK1 [G] feature - Access (Доступ) count: INTEGER -- Число элементов стека item: G is -- Элемент вершины стека require not empty do ... end feature - Status report (Отчет о статусе) empty: BOOLEAN is -- Пуст ли стек? do ... end full: BOOLEAN is -- Заполнен ли стек? do ... end feature - Element change (Изменение элементов) put (x: G) is -- Добавить элемент x на вершину. require not full do ... ensure not empty item = x count = old count + 1 end remove is -- Удалить элемент вершины. require not empty do ... ensure not full count = old count - 1 end end

Оба предложения require и ensure являются возможными; когда они присутствуют, то появляются в фиксированных местах, require - перед предложением local.

Обратите внимание на разделы feature, группирующие свойства по категориям, снабженных заголовками в виде комментариев. Категории Access, Status report, Element change - это несколько примеров из десятков стандартных категорий, используемых в библиотеках и применяемых повсеместно в примерах этой книги.


count < capacity в этом представлении do count := count + 1 representation.put (count, x) ensure not_empty: not empty added_to_top: item = x one_more_item: count = old count + 1 in_top_array_entry: representation @ count = x end remove is -- удалить элемент вершины стека require not_empty: not empty -- i.e. count > 0 do count := count - 1 ensure not_full: not full one_fewer: count = old count - 1 end feature {NONE} -- Implementation (Реализация) representation: ARRAY [G] -- Массив, используемый для хранения элементов стека invariant ... Будет добавлен позднее ... end

Текст класса иллюстрирует простоту работы с утверждениями. Это полный текст, за исключением предложений invariant, задающих инварианты класса, которые будут добавлены позднее в этой лекции. Давайте исследуем различные свойства класса.

Это первый законченный класс этой лекции, не слишком далеко отличающийся от того, что можно найти в профессиональных библиотеках повторно используемых ОО-компонентов, таких как Базовые библиотеки. Одно замечание о структуре класса. Поскольку класс имеет более двух-трех компонентов, возникает необходимость сгруппировать его компоненты подходящим образом. Нотация позволяет реализовать такую возможность введением множества предложений feature. Это свойство группировки компонентов, введенное в предыдущей лекции, использовалось там, как способ задания различного статуса экспорта компонентов. И здесь в последней части класса, помеченной Implementation, это свойство используется для указания защищенности компонента representation. Но преимущества группирования можно использовать и при неизменном статусе экспорта. Его цель - сделать класс простым при чтении и легче управляемым, группируя компоненты по категориям. После каждого ключевого слова feature появляется комментар ий, называемый комментарий к предложению Feature (Feature Clause Comment). Он позволяет дать содержательное описание данной категории - роль компонентов, включенных в этот раздел. Категории, используемые в примере, те же, что и при описании класса STACK1 с добавлением раздела Initialization с процедурой создания (конструктором).

Стандартные категории feature и связанные с ними комментарии к предложениям Feature являются частью общих правил организации повторно используемых библиотек классов.


Содержание раздела