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

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

Парадокс этого совета в том, что он возвращает нас назад к ситуации, в которой все вызовы реализуются через динамическое связывание и требуют несколько большего времени выполнения. Иными словами, соглашения (1) и (2) языка С++, предназначенные для улучшения эффективности, в конце концов, если следовать правилу: "корректность прежде всего", срабатывают против этого!

Неудивительно, что эксперты по С++ не советуют использовать "чересчур много" объектной ориентированности. Уолтер Брайт (Walter Bright), автор одного из самых популярных компиляторов С++, пишет в [Bright 1995]:

Хорошо известно, что чем больше С++ [механизмов] вы используете в некотором классе, тем медленнее его код. К счастью, есть несколько вещей, позволяющих склонить чашу весов в вашу пользу. Во-первых, не используйте без большой необходимости виртуальные функции [т. е. динамическое связывание], виртуальные базовые классы [отложенные классы], деструкторы и т.п. Другой источник разбухания - это множественное наследование [...]. Если у вас сложная иерархия классов с одной или двумя виртуальными функциями, то попробуйте устранить виртуальный аспект и, быть может, сделать то же самое, используя проверки и ветвления.

Иными словами: не прибегайте к использованию ОО-методов. ( В том же тексте отстаивается и "группировка всех кодов инициализации" для локализации ссылки - приглашение нарушить элементарные принципы модульного проектирования, которые, как мы видели, предполагают, что каждый класс должен сам отвечать за все, связанное с его инициализацией.)

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

Ключевые концепции

[x]. С помощью наследования можно определять новые классы как расширение, специализацию и комбинацию ранее определенных классов.

[x]. Класс, наследующий другому классу, называется его наследником, а исходный класс - его родителем. Распространенные на произвольное число уровней (включая ноль) эти понятия становятся понятиями потомка и предка.

[x]. Наследование является ключевым методом как для повторного использования, так и для расширяемости.

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

[x]. С точки зрения модулей наследник расширяет набор служб, предоставляемых его родителями. В частности, это полезно для повторно использования.

[x]. С точки зрения типов отношение между наследником и его родителем - это отношение "является". Оно полезно как для повторного использования, так и для расширяемости.

[x]. Функцию без аргументов можно переопределить как атрибут, но не наоборот.

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