И снова 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

Должен ли код быть сложным?

Для ответа на данный вопрос предлагаю разделить сложность кода на 2 категории - естественная и, соответственно, искусственная.

Естественная сложность кода будет всегда, т.к. причина ее появления - сложность предметной области. Это может быть сложная логика бизнес-процесса. Или возьмем Spring Core - там достаточно сложный жизненный цикл бинов, множество способов описания этих бинов, способов конфигурации, профили.... Я уже не говорю про JDK: модель байт-кода, компиляция, виртуальная машина, classloading, верификация байт-кода, JIT и оптимизации\отмена оптимизаций, сборка мусора, модель памяти, многопоточка и синхронизация доступа, поддержка различных архитектур процессора и ОС, отладка, профилирование, версионирование и обратная совместимость...
Есть понятные пути борьбы с естественной сложностью - микросервисы, слоистая архитектура, DDD и собственно объектно-ориентированное проектирование. Особенность этой сложности - она будет всегда.

Чего быть не должно - так это искусственной сложности. Причем тут бы я снова выделил две подкатегории:
1) то, на что указывают такие штуки как "большой ком грязи" или "божественный класс". Т.е. когда логика выполнения запутана потому, что за этим перестали следить. Или, в худшем случае, изначально не уделяли внимания проектированию. Усугубляет ситуацию здесь отсутствие базовой документации или ее неактуальность, огромное число ненужных настроек, плохой нейминг. Особенность этой категории сложности - вряд ли кто-то, кто увидит такой код, будет его хвалить. Все признают проблему, в т.ч. авторы. Решение - рефакторинг или переписывание кода с нуля.

2) искусственная сложность, сделанная с соблюдением принципов SOLID, ООП и слоистой архитектуры. Типичный пример здесь: микросервис с минимумом бизнес-логики, который можно сделать с использованием паттерна Transaction Script, но вместо этого появляется 3+ слоя, доменная модель, куча интерфейсов с одной реализацией, цепочка из вызовов сервисов, каждый из которых отвечает за одну функциональность по SOLID - авторизация, валидация, маппер, мониторинг, аудит, инициализация сетевых параметров, еще маппер, интеграционные логи, Circuit Breaker... Вроде все по правилам, а из простого сервиса сделан монстр, разобраться в котором очень сложно. Хотя на самом деле - правила нарушается. Как минимум правило KISS - Keep It Simple Stupid. Как максимум - не надо в том же Single Responsibility из SOLID идти до конца и для каждой функциональности, занимающей одну строчку код, делать класс. Как минимум делать это прямо сейчас. У нас же архитектура в коде. Код можно менять. В отличие от архитектуры здания, например. А разработка - это искусство компромиссов. Ну а главная проблема этой категории сложности - авторы кода точно ее не признают. Раз пишут такой код)

Итого - с любой сложностью можно и нужно бороться. Но особенно вредна искусственная сложность. По определению)

#arch #solid #complexity #principles #dev_compomisses