Читать онлайн «Основы объектно-ориентированного программирования». Страница 94

[x]. Работа компилятора не тривиальна. Как выяснится при изучении наследования, для потомка класса ARRAY возможно переопределить любой компонент класса и эти переопределения могут быть косвенно вызваны через динамическое связывание. Поэтому компилятор должен выполнять тщательный анализ для проверки корректности изменений массива. Для научных приложений, интенсивно использующих массивы, современные компиляторы от ISE и других компаний сегодня могут генерировать код, столь же эффективный, как написанный вручную на C или Fortran.

Класс ARRAY предоставляет возможность, косвенно относящуюся к вопросам этой лекции, но полезную на практике. Объявление компонента item фактически определяет и его синоним - инфиксную операцию10.4) следующим образом:

infix "@", item (i: INTEGER): G is...

Здесь задаются два имени компонента: infix "@" и item как синонимы, обозначающие один и тот же компонент, заданный определением.

В общем, объявление компонентов в форме:

a, b, c... "Описание компонента"

рассматривается как краткая форма записи последовательности объявлений:

a "Описание компонента"

b "Описание компонента"

c "Описание компонента"

...

с одним и тем же "Описанием компонента".

Это применимо как для атрибутов (где "Описание компонента" имеет форму: некоторый_тип), так и для подпрограмм (is тело_программы).

Нотация, применяемая в этом примере для доступа к массиву, достаточно проста. Она совместима с механизмами доступа для других структур, хотя, заметим, инструкция a.item(i) более многословна, чем традиционное a[i], встречающееся с некоторыми вариациями в Pascal, C, Fortran и других языках. Определяя "@" как синоним item, можно превзойти традиционные языки в их собственной игре за краткость записи. Написав a @ i, реализуем мечту, - запись требует на одно нажатие клавиши меньше, чем даже С++!. Заметим снова, что это не специальный механизм языка, но прямое применение общей ОО-концепции, компонент-оператора, скомбинированного с нотацией синонима.

Как всегда нужно убедиться, что ОО-техника, введенная в интересах повторного использования, расширяемости и надежности, не влечет потерю производительности. Этот вопрос уже поднимался при рассмотрении массивов. Теперь необходимо с этих позиций проэкзаменовать механизм универсализации в целом. Какова цена универсализация?

В частности, этот вопрос возникает из-за опыта С++, где универсализация, известная как механизм шаблонов, представляла одно из поздних добавлений к языку. Выяснилось, что некоторые компиляторы воспринимают введение универсализации буквально, генерируя различные копии методов класса для каждого фактического родового аргумента! В результате в литературе по С++ предупреждают программистов об опасности широкого использования шаблонов:

Число создаваемых экземпляров шаблона - уже проблема для некоторых пользователей С++. Если пользователь создает List<int>, List<String>, List<Widget> и List<Blidget> (где Widget и Blidget классы, определенные пользователем) и вызывает head, tail и insert для всех четырех объектов, то каждая из этих функций будет создана в четырех экземплярах (из-за родового порождения). Вместо этого широко применимый класс List мог бы создать единственный экземпляр каждой функции применимый для различных типов.10.5)

Авторы этого предупреждения (С++ эксперты из AT&T, один из них соавтор официальной С++ документации [Ellis 1990]) продолжают предлагать различные способы, позволяющие избежать порождения шаблонов. Но универсализация не предполагает дублирование кода. При хорошо спроектированном языке и хорошем компиляторе можно генерировать единый код компонентов родового класса, так что последующие добавления потребуют минимальных затрат:

[x]. времени компиляции;

[x]. размера сгенерированного кода;

[x]. времени выполнения;

[x]. памяти, требуемой для выполнения.

Работая в такой среде, можно использовать всю мощь универсализации, не опасаясь потери производительности, как на этапе компиляции, так и выполнения.

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

Первое: в наших усилиях гарантирования безопасности типов мы заняли чересчур консервативную позицию. Конечно, некорректно пытаться втолкнуть круг в стек банковских счетов. Трудно вообразить, какому приложению нужен стек, содержащий точки и банковские счета. Но рассмотрим графическое приложение, для которого вполне естественен стек, содержащий круги, прямоугольники, точки. Такая потребность кажется довольно разумной, но пока мы не можем удовлетворить ее. Система типов, определенная до сих пор, отвергнет вызов figure_stack.put(that_point) если тип figure_stack был объявлен как STACK [FIGURE], а that_point - тип, отличный от FIGURE. Дадим пока имя рассматриваемым структурам и назовем их полиморфными структурами данных (polymorphic data structure). Вызов, стоящий перед нами - как поддержать эти структуры без потери преимуществ безопасности типов.

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

Для обеих этих проблем ОО-метод обеспечивает простые и элегантные решения, оба основанные на комбинировании универсализации и наследования.

[x]. Классы могут иметь формальные родовые параметры, представляющие типы.

[x]. Родовые классы служат для описания общих контейнерных структур данных, реализуемых одинаково, независимо от элементов, которые они содержат.

[x]. Универсализация требуется только в типизированном языке, гарантирующем статически проверяемую безопасность типов.

[x]. Клиент родового класса должен предоставлять фактические типы для формальных параметров.

[x]. Единственные допустимые операции над сущностью, чей тип является формальным родовым параметром, - это операции, применимые к любому типу. Сущность может быть правой и левой частью оператора присваивания, фактическим аргументом подпрограммы или операндом теста на равенство или неравенство.

[x]. Понятие массива не требует специального языкового механизма и вполне укладывается в обычную схему родового библиотечного класса.

[x]. Более гибкое и продвинутое использование универсализации - полиморфные структуры данных и ограниченная универсализация - требует введения наследования.

Один из первых языков, поддерживающий универсализацию - LPG [Bert 1983]. Язык Ada сделал эту концепцию широко известной введением механизма родовых пакетов.

Универсализация была также введена в языки формальной спецификации, такие как Z, CLEAR и OBJ-2, на которые были ссылки в лекции 6 по АТД. Родовой механизм, описанный здесь, был построен на основе механизма, представленного в ранней версии Z [Abrial 1980] [Abrial 1980a] и расширенного в [M 1985b].

Если не считать эту книгу, то одним из первых ОО-языков, поддерживающих универсализацию, был DEC's Trellis язык [Schaffert 1986].

Это упражнение немного специфично - оно ставит вопрос, детальный ответ на который будет дан позднее в этой книге. Его цель - дать возможность сравнить ваше решение с решением, предложенным в книге. Оно особенно полезно, если вы не знакомы с решениями, предлагаемыми в ОО-языках. Подход языка Ada может помочь в поиске решения, но и без него можно обойтись.