общепринятая практика C++: виртуальные интерфейсные классы по сравнению с шаблонами

Свойства классического объектно-ориентированного полиморфизма:

• объекты связываются во время выполнения; это более гибко, но также потребляет больше ресурсов (ЦП) во время выполнения
• строгая типизация обеспечивает несколько большую безопасность типов, но необходимость dynamic_cast (и его потенциал взорвать лицо клиента ) может легко компенсировать это
• , вероятно, более широко известный и понятный, но «классические» иерархии глубокого наследования кажутся мне ужасными

Свойства полиморфизма времени компиляции по шаблону:

• связывание времени компиляции допускает более агрессивные оптимизации , но предотвращает гибкость во время выполнения
• утиная типизация может показаться более неудобной, но сбои, как правило, возникают во время компиляции
• иногда труднее читать и понимать; без понятий, диагностика компилятора иногда может раздражать

Обратите внимание, что нет необходимости делать выбор ни по одному из них. Вы можете свободно смешивать и то и другое (и многие другие идиомы и парадигмы). Часто это приводит к очень впечатляющему (и выразительному) коду. (См., Например, такие вещи, как стирание шрифтов.) Чтобы получить представление о том, что возможно за счет умного смешения парадигм, вы можете просмотреть «Современный дизайн C ++» Александреску.

Это что-то вроде ложной оппозиции. Да, в основном наследование и виртуальные функции используются в iostreams , которые очень старые и написаны в совершенно другом стиле, чем остальные библиотеки std .

Но многие из самых «крутых» современных библиотек C ++, такие как boost, действительно используют полиморфизм времени выполнения, они просто используют шаблоны, чтобы сделать его более удобным в использовании.

boost :: any и std :: tr1 :: function (ранее также из boost) - прекрасные примеры.

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

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

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

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

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