[x]. Надежность: благодаря явному объявлению типов компилятор сможет найти ошибочные операции еще на этапе компиляции, не допуская их проявления при выполнении. В фундаментальных операциях ОО-вычислений вызов компонента имеет форму
Ключ к надежности - следование принципу 'предотвратить, а не лечить'. Исследования показали, что стоимость исправления ошибки астрономически возрастает, когда затягивается ее обнаружение. Статическая типизация, позволяющая раннее обнаружение ошибок, - фундаментальный инструмент в борьбе за надежность.
Без учета требований надежности явное объявление типов было бы не нужно так же как универсализация. Остаток этой лекции обращается к языкам со статической типизацией, т.е. языкам, которые требуют объявления каждой сущности и задают правила, позволяющие компиляторам обнаруживать несоответствие типов до выполнения. В не статически типизированных языках, таких как Smalltalk, универсализация не имеет смысла. Язык упрощается, но не защищает от схем вида:
my_stack.put (my_circle)
my_account := my_stack.item
my_account.withdraw (5000)
где элемент, полученный из вершины стека, рассматривается как банковский счет, хотя в действительности это круг, что можно понять из первой инструкции. Выполнение программы закончится, при попытке получить пять тысяч долларов от 'дырки от бублика'.
Статическая типизация защищает от подобных неудач. Совмещение типизации с требованием повторного использования приведет нас к механизму универсализации.
Родовые классы
Согласование статической типизации с требованием повторного использования для классов, описывающих контейнерные структуры, означает, как показано на примере стека, что мы хотим одновременно иметь возможность:
[x]. Объявить тип каждой сущности, появляющейся в классе стека, включая сущности, представляющие элементы стека.
[x]. Написать класс так, чтобы он не содержал никаких намеков на тип элемента стека, и следовательно, мог использоваться для построения стеков с элементами произвольных типов.
На первый взгляд эти требования кажутся несовместимыми, но на самом деле это не так. Первое требование заставляет нас объявить тип. Но вовсе не требуется, чтобы тип в объявлении был конкретным! Назвав имя типа, мы умиротворим механизм проверки. ('Назови свой страх - и он уйдет'). В этом идея универсализации: получить класс с параметром, задающим тип, снабдить его именем, назвав его формальным родовым параметром.
Объявление родового класса
По соглашению родовой параметр обычно, использует имя
Согласно синтаксису, формальные родовые параметры заключаются в квадратные скобки, следующие за именем класса, подобно синтаксису параметризованного АТД в предыдущей лекции. Например:
indexing
description: 'Стек элементов произвольного класса G'
class STACK [G] feature
count: INTEGER
-- Количество элементов в стеке
empty: BOOLEAN is
-- Есть ли элементы?
do ... end
full: BOOLEAN is
-- Стек заполнен?
do ... end
item: G is
-- Вершина стека
do ... end
put (x: G) is
-- Втолкнуть x в стек.
do ... end
remove is
-- Вытолкнуть элемент из стека.
do ... end
end -- class STACK
Формальный родовой параметр
Использование родового класса
Клиент может использовать родовой класс для объявления собственных сущностей, задающих стек. В этом случае в момент объявления следует задать фактический тип элементов стека - фактический родовой параметр, например:
sp: STACK [POINT]
