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

Даже в языке, заставляющем программиста отвечать за выбор политики связывания (такое решение принято в C), предопределенное значение должно быть противоположным. Вместо того, чтобы требовать объявлять динамически связываемые функции виртуальными ( virtual), язык должен был бы использовать динамическое связывание по умолчанию и разрешить программистам выделять словом static(или каким-нибудь другим) компоненты, для которых они хотели бы запросить оптимизацию, доверив им самим (в традиции C и С++) удостоверяться в том, что она допустима.

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

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

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

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

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

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

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