И снова SOLID, и снова OCP

Я уже говорил, что означает Open Close Principe (OCP) https://t.me/javaKotlinDevOps/181. Но появилась еще одна мысль. Наверное самая лучшая реализация этого принципа - это система с плагинами. Там мы очень четко говорим - что open, что close. И само проектирование такой системы накладывает больше ответственности, а значит есть шанс, что разделение open - close будет более устойчивым со временем. Минус тут только один - проектировать такую систему долго, а нужна она далеко не всегда.

P.S. И еще одна мысль - раз у нас ООП язык, и для расширения мы задумываемся об использовании композиции или агрегации - очень похоже на то, что проектировщик ядра (библиотеки), которую мы расширяем, где-то ошибся.

P.P.S. И последняя - у проектировщика ядра и у пользователей этого ядра часто противоположные задачи. В ядре мы стремимся закрыть все лишнее (close), чтобы обеспечить устойчивость и соблюдение code quality. А когда мы используем ядро - в тестах или расширяя его функционал - нам часто хочется залезть во внутрь и что-то поменять. Или получить доступ к внутреннему состоянию (open). Надо искать баланс.

#solid

Почему SOLID?

Почему именно SOLID считается базовыми принципами разработки? Почему именно пять? Почему именно эти пять?

Я думаю, что за основной причиной нужно идти в словарь. Solid — крепкий, твёрдый, надёжный, серьёзный. Роберт Мартин хотел, чтобы принципы легко запоминались — у него это получилось)

Приведу пару аргументов.
I — interface segregation — принцип, конечно, полезный. Но технический по сути, а главное — является частным случаем S — single responsibility.
S, O, D — могут применяться как на уровне классов, так и на уровне модулей приложения.
L — это уровень классов, накладывает на них более строгие требования, чем обеспечивают «из коробки» ООП языки.

Есть ещё полезные принципы — DRY, KISS, которые сюда не попали.

Из всего вышесказанного никак не следует, что SOLID-принципы плохие. Я о том, что их на самом деле больше.

#solid