Comments 4
Идея в целом понятна. Проблема в том, что полиморфизм в иерархии базового класса Product и его специализаций (что требует работы с указателями) подменяется полиморфизмом в иерархи т.н. "декораторов" (базовый класс Properties и его специализаций), что по-прежнему требует указателей. С моей точки зрения, в качестве универсального рецепта, пример неубедительный. Хотя возможны специальные случаи где подобный дизайн может чем-то помочь.
Это не статья, это курсовая работа студента начавшего изучать ООП и С++.
Немного по существу.
1. Тема иммутабельности не раскрыта - зачем она вообще нужна эта иммутабельность? В чем проблема мутабельности?
2. Если уж решили использовать наследование и работаете с объектами ExpandProduct через указатель на базовый класс Product, то позаботьтесь хотябы о виртуальном деструкторе в этом базовом классе, иначе все эти ваши std::shared_ptr<Manufacturer> до лампочки.
то позаботьтесь хотябы о виртуальном деструкторе в этом базовом классе, иначе все эти ваши std::shared_ptr до лампочки.
Разделяю ваше мнение по поводу уровня статьи и подозрения о том, что автор плохо знает C++.
Но как раз в случае с std::shared_ptr наличие виртуального деструктора в базовом классе не всегда необходимо, т.к. shared_ptr умудряется вызывать деструктор именно того класса, который был в shared_ptr передан: https://wandbox.org/permlink/yNve1UFjSbaJCHx6
Хочется верить, что автор статьи знает про эту особенность и намеренно ее использует. Но, боюсь, это у него случайно получилось.
Все верно, согласен с вами. Подзабыл про этоу особенность shared_ptr. Там при создании shared_ptr генерируется делитер с вызовом правильного деструктора, так как статический тип в тот момент известен, и он сохраняется в ControlObject-е этого shared_ptr. Так что да, будет вызван деструктор ExpandProduct не смотря на то, что базовый класс не имеет виртуального деструктора. Но проблема остается для других типов с менеджметом ресурсов которые не обладают такой особенностью как shared_ptr.
Чистый код: Данные