Основы объектно-ориентированного программирования
Ограничение родового параметра
Эти наблюдения дают решение. Мы должны оперировать исключительно терминами классов и типов.
Потребуем, чтобы любой фактический параметр, используемый классом VECTOR (в других примерах по аналогии), был типом, поставляемым с множеством операций: infix "+", zero для инициализации суммы и т.д. Владея наследованием, мы знаем, как снабдить тип нужными операциями, - нужно просто сделать его потомком класса, отложенного или эффективного, обладающего этими операциями.
Синтаксически это выглядит так:
class C [G -> CONSTRAINING_TYPE] ... Все остальное как обычно ...
где CONSTRAINING_TYPE - произвольный тип, именуемый родовым ограничением (generic constraint). Символ -> обозначает стрелку на диаграммах наследования. Результат этого объявления в том, что:
- в роли фактических родовых параметров могут выступать лишь типы, совместимые с CONSTRAINING_TYPE;
- в классе 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] приведет к ошибке времени компиляции.
Абстрактный характер NUMERIC не вызывает никаких проблем. Фактический параметр при порождении может быть как эффективным (примеры выше), так и отложенным (VECTOR [NUMERIC_COMPARABLE]), если он порожден от NUMERIC.
Аналогично описываются класс словаря и класс, поддерживающий сортировку:
class DICTIONARY [G, H -> HASHABLE] ... class SORTABLE [G -> COMPARABLE] ...
