Как стать автором
Обновить

Комментарии 5

Идея в целом понятна. Проблема в том, что полиморфизм в иерархии базового класса 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.

Ух уж этот конь в вакууме... Когда проект пишут разные разработчики начиная с 2014 года, разной компетенции, все принципы идут нахрен. В реальной жизни придется работать с дикой мешаниной из легаси, архитектурными выкрутасами и дикими костылями. Чтоб было понимание происходящего, опишу ситуацию аналогией.

Мы строим дом. Заложил фундамент. Бизнес говорит , тут в стене должна быть дыра.но стены ещё нету. Один тип делает всё стены с дырой. (Потом где ненужно -замажем). Не дошли до крыши. Давай делать крыльцо- комиссия приезжает. Нахуй крышу, делаем крыльцо. Один делает из бетона другой из камней. Сливают вместе этого Франкенштейна - приставляют к стене. Оп-па у проекта оказывается двери нет. Похуй. Берём огромную болгарку режим стену. Пока это делали, пару разрабов сказали- Ну нахуй, и ушли. Но только они знали как этот дом должен выглядеть. Пол года перекрашивали стены. Нужен второй этаж. Такой же как первый. Копируем , вставляем. Первый этаж рухнул - стены были нерасчитаны на такой вес. Приходит менеджер , какого хуя так долго? Тут копировать -вставить.!! На вам ещё в помощь чуваков с других проектов. Один делал самолёты. Другой отлично плавает на дальние дистанции. Пусть у вас трубы проводят. Ну все. Хуево но готово- нужно крышу ставить. И тут выясняется что пока мы стены красили подвал залило водой. Потому что крыши не было. Уже въехало 2 семьй!!!! Откачиваем воду. Срочно приходит правка. Эту стену делаем из стекла - так модно! , Но там туалеты!? Да похуй - делай. Меняем стену на стекло. Теперь будет летом жарко, зимой холодно! Заебись . И тут отказывается фундамент был херово спроектирован. И подвал завален костылями - чтоб не провалился. Меняем фундамент, по ночам, потому что такой хуйни в смете не заложенно. Нужно блядь балконны вешать. Кстати , крышу так и не сделали. И если ты житель последнего этажа , по ночам тебе идёт дождь прямо в морду....

Вот с чем в реальности работать. За последние 10 лет в коммерческих проектах восновном такая херня творится. Ни разу не видел что бы был проект весь сделан по принципам. Особенно которые долго в разработке типа корпоративных сервисов.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории