Начинающие программисты зачастую выполняют наследование от классов-значений, таких как класс

(стандартный или иной) просто чтобы "добавить больше функциональности". Однако определение свободной функции (не являющейся членом) существенно превосходит создание класса по следующим причинам.

• Свободные функции хорошо вписываются в существующий код, который работает с объектами

. Если же вместо этого вы предоставляете класс , вам придется вносить изменения в ваш код, заменяя типы и сигнатуры функций.

• Функции интерфейса, которые получают параметры типа

, при использовании наследования должны сделать одно из трех: а) отказаться от дополнительной функциональности (бесполезно), б) копировать свои аргументы в объекты (расточительно) или в) преобразовать ссылки на в ссылки на (затруднительно и потенциально некорректно).

• Функции-члены

не должны получить больший доступ к внутреннему устройству класса , чем свободные функции, поскольку класс , вероятно, не имеет защищенных () членов (вспомните — этот класс не предназначался для работы в качестве базового).

• Если класс

скрывает некоторые из функций класса (а переопределение невиртуальных функций в производном классе не является перекрытием — это просто сокрытие), это может вызвать неразбериху в коде, работающем с объектами string, которые создаются автоматическим преобразованием из класса .

Словом, лучше добавлять новую функциональность посредством новых свободных (не являющихся членами) функций (см. рекомендацию 44). Чтобы избежать проблем поиска имен, убедитесь, что вы поместили функции в то же пространство имен, что и тип, для расширения функциональности которого они предназначены (см. рекомендацию 57). Некоторые программисты не любят свободные функции из-за их синтаксиса

вместо , но это не более чем вопрос привычки.

Но что если класс

наследуется из класса для добавления состояний, таких как кодировка или кэшированное значение количества слов? Открытое наследование не рекомендуется и в этом случае, поскольку класс не защищен от срезки (см. рекомендацию 54), и любое копирование в молча уберет все старательно хранимые дополнительные состояния.

И наконец, наследование класса с открытым невиртуальным деструктором рискует получить эффект неопределенного поведения при удалении указателя на объект типа

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

Примеры

Пример 1. Композиция вместо открытого или закрытого наследования. Что делать, если вам нужен тип

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

Конечно, писать транзитные функции для всех функций-членов, которые вы хотите сохранить, — занятие утомительное, но зато такая реализация существенно лучше и безопаснее, чем использование открытого или закрытого наследования.

Пример 2.

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

[Dewhurst03] §70, §93 • [Meyers97] §33 • [Stroustrup00] §24.2-3, §25.2

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