того же класса, проходя по разным ветвям наследования:
Рис. 2.1. Дублируемое наследование В этом случае язык должен обеспечить точные правила, определяющие, что происходит с
компонентами, наследованными повторно от общего предка (на рисунке - это A). В некоторых случаях желательно, чтобы компонент из A создавал только один компонент в D ( разделение ), а в других - нужно, чтобы он создавал два ( дублирование ). Разработчики должны обладать гибкими средствами, позволяющими предписывать одну из возможностей независимо для каждого компонента.
При дублируемом наследовании судьбой компонентов должны управлять точно определенные правила, позволяющие разработчикам выбирать для каждого такого компонента разделение, либо дублирование.
Ограниченная универсальность (Constrained genericity)
Сочетание универсальности и наследования дает полезную технику - ограниченную универсальность (constrained genericity). Теперь вы можете определить класс с родовым параметром, представляющим не произвольный тип, а лишь тип, являющийся потомком некоторого класса.
Родовой класс SORTABLE_LIST описывает списки; он содержит компонент sort, сортирующий элементы списка в соответствии с заданным отношением порядка. Параметр этого родового класса задает тип элементов списка. Но этот тип не может быть произвольным: он должен поддерживать отношение порядка. Фактический родовой параметр должен быть потомком библиотечного класса COMPARABLE, описывающего объекты, снабженные отношением порядка. Ограниченная универсальность позволяет объявить наш родовой класс следующим образом: SORTABLE_LIST [G -" COMPARABLE] .
Механизм универсальности должен поддерживать форму ограниченной универсальности.
Переопределение (redefinition)
Когда класс является наследником другого класса, может потребоваться изменить реализацию или другие свойства некоторых наследованных компонент. Класс SESSION, управляющий сеансами пользователей в операционной системе, может иметь компонент terminate, выполняющий чистку в конце сеанса. Его наследником может быть класс REMOTE_SESSION, управляющий сеансом удаленного компьютера в сети.
Если завершение удаленного сеанса требует дополнительных действий, таких как, например, уведомление удаленного компьютера, класс REMOTE_SESSION переопределит компонент terminate.
Переопределение может повлиять на реализацию компонента, его сигнатуру (тип
аргументов и результата) и спецификацию.
Должно быть возможным переопределить спецификацию, сигнатуру и реализацию наследованного компонента.
Полиморфизм
При наследовании, требование статической типизации, о котором говорилось выше, становится ограничивающим, если бы оно означало, что каждая сущность типа C может быть связана только с объектом точно такого же типа С. Например в системе управления навигацией сущность типа BOAT нельзя было бы использовать для объектов класса MERCHANT_SHIP или SPORTS_BOAT, хотя оба класса являются потомками класса BOAT.
|Как уже отмечалось, "сущность" - это имя, к которому во время выполнения могут присоединяться различные значения. Сущность - это обобщение традиционного понятия переменной. |
Полиморфизм (polymorphism) - способность присоединять к сущности объекты различных возможных типов. В статически типизированной среде полиморфизм не будет произвольным, а будет контролироваться наследованием.
Должна иметься возможность в период выполнения присоединять к сущности объекты различных возможных типов под управлением наследования.
Динамическое связывание
Сочетание последних двух механизмов, переопределения и полиморфизма, непосредственно предполагает следующий механизм. Допустим, есть вызов, целью которого является полиморфная сущность, например сущность типа BOAT вызывает компонент turn. Различные потомки класса BOAT, возможно, переопределили этот компонент различными способами. Ясно, что должен существовать автоматический механизм, гарантирующий, что версия turn всегда соответствует фактическому типу объекта, вне зависимости от того, как объявлена сущность. Эта возможность называется динамическим связыванием (dynamic binding).
Вызов сущностью компонента всегда должен запускать тот компонент, который соответствует типу присоединенного объекта, а не типу сущности.
При различных выполнениях одного и того же вызова могут запускаться разные компоненты.
Динамическое связывание оказывает большое влияние на структуру ОО-приложения, поскольку дает возможность разработчикам писать простые вызовы, например объект my_boat вызывает компонент turn. В действительности, данный вызов означает несколько возможных вызовов, зависящих от соответствующих ситуаций времени выполнения. Это упраздняет необходимость многих повторных проверок (является ли объект merchant_ship? Является ли он sports_boat?), наводняющих программные продукты, создаваемые при обычных подходах.
Выяснение типа объекта в период выполнения
Разработчики ОО-ПО вскоре вырабатывают здоровую неприязнь к любому стилю вычислений, основанному на явном выборе между различными типами объекта. Полиморфизм и
динамическое связывание намного предпочтительнее. Однако в некоторых случаях объект приходит извне, так что автор ПО не имеет возможности с определенностью предсказать его тип. В частности, это случается, если объект извлекается из внешних хранилищ, получен по сети или передан некоторой другой системой.
Тогда ПО нуждается в механизме, обеспечивающем безопасный способ доступа к объекту без нарушения ограничений статической типизации. Такой механизм должен проектироваться с большой аккуратностью, так чтобы не утратить пользы от полиморфизма и динамического связывания.
Операция попытка присваивания (assignment attempt) удовлетворяет этим требованиям. Это условная операция: она пытается присоединить объект к сущности; если при выполнении операции тип объекта соответствует типу сущности, то она действует как нормальное присваивание; в противном случае сущность получает специальное значение void. Итак, можно управлять объектами, тип которых не известен наверняка, не нарушая безопасности системы типов.
Необходимо иметь возможность определять во время выполнения, соответствует ли тип объекта статически заданному типу.
Отложенные (deferred) свойства и классы
Внекоторых случаях, для которых динамическое связывание дает элегантное решение, устраняя необходимость явных проверок, не существует начальной версии компонента, подлежащего переопределению. Например, класс BOAT может быть настолько общим, что не может обеспечить реализацию turn по умолчанию. Все же, мы хотим иметь возможность вызвать компонент turn сущностью типа BOAT, если мы уверены, что во время выполнения она будет получать значение объектов таких полностью определенных типов как, например,
MERCHANT_SHIP и SPORTS_BOAT.
Втаких случаях BOAT может объявляться как отложенный класс (класс, который не полностью реализован) и с отложенной реализацией компонента turn. Отложенные свойства и классы все же могут иметь утверждения, описывающие их абстрактные возможности, но их реализация откладывается для классов потомков. Если класс не является отложенным, - он считается эффективным.
Необходимо иметь возможность написания класса или компонента как отложенного, то есть специфицированного, но не полностью реализованного.
Отложенные классы (также называемые абстрактными классами) особенно важны для ООанализа и высокоуровневого проектирования, поскольку они делают возможным задать основные аспекты системы, оставляя детали до более поздней стадии.
Управление памятью (memory management) и сборка мусора (garbage collection)
Может показаться, что этот критерий метода и языка должен принадлежать к следующей категории - реализации и среде. На самом деле он принадлежит к обеим категориям. Важнейшие требования предъявляются к языку, остальное - это вопрос хорошей инженерии.
ОО-системы даже в большей степени, чем традиционные системы, за исключением, быть может, Lisp, имеют тенденцию создания большого числа объектов, иногда со сложными взаимозависимостями. Политика, возлагающая на разработчиков ответственность за управление
памятью, вредит и эффективности процесса разработки, и безопасности полученной системы. Трудно утилизировать память, занятую более не нужными объектами, усложняются программы, все это требует времени разработчиков, увеличивается риск некорректной обработки областей памяти. В хорошей ОО-среде управление памятью будет автоматическим, под контролем сборщика мусора (garbage collector) - компонента системы периода выполнения (runtime system).
Автоматическая сборка мусора - это проблема языка, так же как и реализации. Если язык явно не спроектирован для автоматического управления памятью, то зачастую реализация становится невозможной. Это справедливо для языков, где, например, указатель на объект определенного типа может быть преобразован (используя кастинг - cast ) в указатель другого типа или даже в целое число, - такие средства делают невозможным создание надежного сборщика мусора.
Язык должен давать возможность надежного автоматического управления памятью, а реализация должна обеспечить наличие автоматического менеджера, управляющего памятью, в функцию которого входит сборка мусора.