Чистый код: Принцип открытости закрытости (OCP)

[hardtop]

Странная статья, начало и конец писали как будто 2 разных человека. Начали с GetBook, а потом переключились на Product. Использование double для цены (вместо decimal) - прекрасный способ выстрелить себе в ногу.

[amazingname]

Что насчёт принципа разделения интерфейсов?

[xentoo]

Ага. И еще зависимость от абстракций (dependency inversion) автор профукал. Расширять он продукт захотел, и сразу же зависимый от простого класса интерфейс создал. Если автор планирует сразу расширяемый "продукт" то ему надо начинать с абстрактного класса. Ну так себе..

[AzatJ]

Непонятно, почему первые два метода нарушают принцип, GetBookList возвращает IEnumerable, а пользователь уже может с этим IEnumerable сделать все что угодно

[grgdvo]

Больше похоже, что пример в начале нарушает SRP, а не OCP.

[mrobespierre]

Поддержу, статья про другой принцип SOLID. Принцип открытости-закрытости простыми словами звучит так: "любые изменения в систему должны вноситься за счёт написания нового кода, а не изменения старого". Т.е. мы пишем новый модуль/компонент и заменяем им старый, остальные модули/компоненты не изменяются и работают как раньше. Интерфейс, кстати, действительно в этом помогает: замена одной реализации интерфейса на другую - идеальная демонстрация.

[Gsom1]

Если мы просто нарезаем на тонкие интерфейсы, что имеется ввиду под расширением?
interface IRepository : IDisposable where T : class { IEnumerable GetAll(); }


[glebchansky]

Что ж это за привычка-то такая делать пример кода на плюсах, когда на них кодишь откровенно плохо?

1) Передача строки в конструктор/сеттер класса по значению, а дальше просто присваивание полю класса без мув, в итоге 2 лишних копирования в худшем случае

2) Аналогично передача жирного std::list и отсутствие его перемещения в поле класса

3) Геттер строки без константной ссылки в классе Product. Там будет чистейшее копирование, это не то место, где будет оптимизация NRVO/Copy Elision

4) Использование `operator +` для строк вместо append, из-за чего там также куча глубоких копирований строк

[voldemar_d]

С оператором + не всё так просто:

https://en.cppreference.com/w/cpp/string/basic_string/operator%2B

Емнип, как раз в std::string предприняты усилия, чтобы оператор + не делал лишних копирований.

[glebchansky]

Это зависит от реализации. Мой посыл в том, чтобы юзать именно append (push_back по возможности для одиночных чаров)

[voldemar_d]

А чем append для одиночного чара не подходит?

[glebchansky]

const char* принимает потому что вместо char. Это не столь критично, но тем не менее

Edit: хоть там и есть перегрузка (size_t n, char symbol), все равно по возможности лучше пушбек использовать, быстрее будет теоретически

[rukhi7]

Здесь представлены сразу несколько нарушений ограничивающих гибкость кода.

на мой взгляд очень витиевато, вряд ли вас можно понять.

На самом деле достаточно рассмотреть единственное нарушение которое не просто ограничивает, а убивает на корню всю гибкость кода.

Дело в том что тип этого интерфейса не полностью определен так как для его определения нужен еще тип параметра темплейта.

Код который работает с таким интерфейсом определенным для какого-то класса А гарантированно не сможет работать если вместо указателя на IRepository<А> в него попадет указатель на IRepository<B> :

например:

var *ptr = getPtr();

А item;

ptr->Create(item);//странная функция создания объекта который уже создан, кстати, но бог с ней, что есть с тем и работаем

глядя на такой примитивный пример сразу видно что он должен быть привязан к типу А, соответственно он даже теоретически не может работать для другого типа B без того чтобы в этот вызывающий код вносить изменения, то есть расширяемость отсутствует как явление при использовании параметризованного интерфейса.

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

[AlexeySu]

Параметры в виде shared_ptr точно нарушают ISP

[Pubert]

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