Критерии объектной ориентации

Выяснение типа объекта в период выполнения

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

Тогда ПО нуждается в механизме, обеспечивающем безопасный способ доступа к объекту без нарушения ограничений статической типизации. Такой механизм должен проектироваться с большой аккуратностью, так чтобы не утратить пользы от полиморфизма и динамического связывания.

Операция попытка присваивания (assignment attempt) удовлетворяет этим требованиям. Это условная операция: она пытается присоединить объект к сущности; если при выполнении операции тип объекта соответствует типу сущности, то она действует как нормальное присваивание; в противном случае сущность получает специальное значение void. Итак, можно управлять объектами, тип которых не известен наверняка, не нарушая безопасности системы типов.

Необходимо иметь возможность определять во время выполнения, соответствует ли тип объекта статически заданному типу.

Отложенные (deferred) свойства и классы

В некоторых случаях, для которых динамическое связывание дает элегантное решение, устраняя необходимость явных проверок, не существует начальной версии компонента, подлежащего переопределению. Например, класс BOAT может быть настолько общим, что не может обеспечить реализацию turn по умолчанию. Все же, мы хотим иметь возможность вызвать компонент turn сущностью типа BOAT, если мы уверены, что во время выполнения она будет получать значение объектов таких полностью определенных типов как, например, MERCHANT_SHIP и SPORTS_BOAT.

В таких случаях BOAT может объявляться как отложенный класс (класс, который не полностью реализован) и с отложенной реализацией компонента turn. Отложенные свойства и классы все же могут иметь утверждения, описывающие их абстрактные возможности, но их реализация откладывается для классов потомков. Если класс не является отложенным, - он считается эффективным.

Необходимо иметь возможность написания класса или компонента как отложенного, то есть специфицированного, но не полностью реализованного.

Отложенные классы (также называемые абстрактными классами) особенно важны для ОО-анализа и высокоуровневого проектирования, поскольку они делают возможным задать основные аспекты системы, оставляя детали до более поздней стадии.

Управление памятью (memory management) и сборка мусора (garbage collection)

Может показаться, что этот критерий метода и языка должен принадлежать к следующей категории - реализации и среде. На самом деле он принадлежит к обеим категориям. Важнейшие требования предъявляются к языку, остальное - это вопрос хорошей инженерии.

ОО-системы даже в большей степени, чем традиционные системы, за исключением, быть может, Lisp, имеют тенденцию создания большого числа объектов, иногда со сложными взаимозависимостями. Политика, возлагающая на разработчиков ответственность за управление памятью, вредит и эффективности процесса разработки, и безопасности полученной системы. Трудно утилизировать память, занятую более не нужными объектами, усложняются программы, все это требует времени разработчиков, увеличивается риск некорректной обработки областей памяти. В хорошей ОО-среде управление памятью будет автоматическим, под контролем сборщика мусора (garbage collector) - компонента системы периода выполнения (runtime system).

Автоматическая сборка мусора - это проблема языка, так же как и реализации. Если язык явно не спроектирован для автоматического управления памятью, то зачастую реализация становится невозможной. Это справедливо для языков, где, например, указатель на объект определенного типа может быть преобразован (используя кастинг - cast ) в указатель другого типа или даже в целое число, - такие средства делают невозможным создание надежного сборщика мусора.

Язык должен давать возможность надежного автоматического управления памятью, а реализация должна обеспечить наличие автоматического менеджера, управляющего памятью, в функцию которого входит сборка мусора.