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

Рис. 16.5. Поэлементное сложение векторов

Но подобная схема не работает! Операция + , которую мы определили для сложения векторов ( VECTOR ), здесь применяется к объектам совсем другого типа ( G ), являющегося родовым параметром. По определению, родовой параметр представлен неизвестным типом - фактическим параметром, появляющимся только тогда, когда нам понадобится для каких либо целей родовой класс. Процесс порождения класса при задании фактического родового параметра называется родовым порождением ( generic derivation). Если фактическим параметром служит INTEGER либо иной тип (класс), содержащий функцию infix "+"правильной сигнатуры, корректная работа обеспечена. Но что если параметром станет ELLIPSE , STACK , EMPLOYEE или другой тип без операции сложения?

С прежними родовыми классами: контейнерами STACK , LIST и ARRAY - этой проблемы не возникало, поскольку их действия над элементами (типа G как формального параметра) были универсальны - операции (присваивание, сравнение) могли выполняться над элементами любого класса. Но для абстракций, подобных векторам, допускающих сложение, нужно ограничить круг допустимых фактических родовых параметров, чтобы быть уверенными в допустимости проектируемых операций.

Этот случай отнюдь не является исключением. Вот еще два примера того же рода.

[x].Предположим, вы проектируете класс, описывающий структуру данных с операцией sort , упорядочивающей элементы структуры в соответствии с некоторым критерием сортировки. Тогда элементы этой структуры должны принадлежать типу, для которого определена операция сравнения infix "<=", задающая порядок для любой пары соответствующих объектов.

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

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

В языке Ada нет классов, но зато есть пакеты для группировки взаимосвязанных типов и операций. Пакет может быть родовым, с родовыми параметрами, представляющими типы. При этом возникает та же проблема: пакет VECTOR_PROCESSING может включать объявление типа VECTOR и эквивалент нашей функции infix "+".

Решение в языке Ada рассматривает необходимые операции, например инфиксное сложение, как родовые параметры. Параметрами пакета могут быть не только типы, как при объектном подходе, но и подпрограммы. Например:

generic

type G is private;

with function "+" (a, b: G) return G is <>;

with function "*" (a, b: G) return G is <>;

zero: G; unity: G;

package VECTOR_HANDLING is

... Интерфейс пакета ...

end VECTOR_HANDLING

Заметим, что наряду с типом G и подпрограммами родовым параметром служит значение zero - нулевой элемент сложения. Типичное использования пакета:

package BOOLEAN_VECTOR_HANDLING is

new VECTOR_HANDLING (BOOLEAN, "or", "and", false, true);

В этом примере логическая операция orиспользуется как сложение, and- умножение, а также задаются соответствующие значения для zero и unity . Подробнее мы обсудим этот пример в одной из следующих лекций курса.

Являясь решением для Ada, данный прием не применим в объектной среде. Основа ОО-подхода - приоритет типов данных над операциями при декомпозиции ПО, чьим следствием является отсутствие независимых операций. Всякая операция принадлежит некоторому типу данных, основанному на классе.Следовательно, возникшая "на пустом месте" функция, скажем, infix "+", не может быть фактическим родовым параметром, стоящим в одном ряду с типами INTEGER и BOOLEAN . То же касается и значений, таких как zero и unity , обязанных знать свое место - быть компонентами класса - вполне респектабельными членами ОО-сообщества.

Эти наблюдения дают решение. Мы должны оперировать исключительно терминами классов и типов.

Потребуем, чтобы любой фактический параметр, используемый классом VECTOR (в других примерах по аналогии), был типом, поставляемым с множеством операций: infix "+", zero для инициализации суммы и т.д. Владея наследованием, мы знаем, как снабдить тип нужными операциями, - нужно просто сделать его потомком класса, отложенного или эффективного, обладающего этими операциями.

Синтаксически это выглядит так:

class C [G -> CONSTRAINING_TYPE] ... Все остальное как обычно ...

где CONSTRAINING_TYPE - произвольный тип, именуемый родовым ограничением (generic constraint). Символ -> обозначает стрелку на диаграммах наследования. Результат этого объявления в том, что:

[x].в роли фактических родовых параметров могут выступать лишь типы, совместимые с CONSTRAINING_TYPE ;

[x].в классе C над сущностью типа G допускаются только те операции, которые допускаются над сущностью CONSTRAINING_TYPE , другими словами, представляющими собой компоненты базового класса этого типа.

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

indexing

description: "Векторы, допускающие сложение"

class

VECTOR [G -> NUMERIC]

... Остальное - как и раньше (но теперь правильно!) ...

После чего ранее некорректная конструкция в теле цикла

Result.put(item (i) + other.item (i), i)

становится допустимой, поскольку item (i) и other.item (i) имеют тип G , а значит, к ним применимы все операции NUMERIC , включая, инфиксный " + ".

Следующие родовые порождения корректны, если полагать, что все классы, представленные как фактические родовые параметры, являются потомками NUMERIC :

VECTOR [NUMERIC]

VECTOR [REAL]

VECTOR [COMPLEX]

Класс EMPLOYEE не порожден от NUMERIC , так что попытка использовать VECTOR [EMPLOYEE] приведет к ошибке времени компиляции.