Здравствуй, дядя Боб
Все знают про SOLID.
Это набор принципов хорошего дизайна программных систем, которые описал Роберт Мартин (Uncle Bob) в своей книге “Чистая архитектура”.
Сейчас знание SOLID требуют в вакансиях на должность программиста, как 10 лет назад требовали знание принципов ООП.
В чём подвох
В чём проблема с SOLID?
Мало кто читал первоисточник, ещё меньше тех кто прочитал и понял в чём же заключается тот или другой принцип. Интернет завален трактовками тех, кто “наконец-то понял”.
Есть и противники SOLID, и ярые поклонники, причём даже поклонники не могут договориться, как понимать тот или иной принцип.
Пользуясь тем что у меня есть блог, и я тоже выскажусь. У меня нет права утверждать что я не ошибся, но я постараюсь осветить то о чём никто не говорил.
От проблемы к решению
SOLID объясняют неправильно. Все рассказывают про принцип, а потом про то как его применить.
От такого объяснения мало толку. “Ага, так можно применить. Но посмотрим на мой код. Вот здесь нужно его применять? А здесь?” Совершенно непонятно.
Нам предлагают решение, толком не объясняя проблему. Пытаются объяснить, “вот это в формулировке принципа означает что…” и появляется ещё больше толкований. У всех разное понимание проблемы, отсюда и споры о решениях и трактовках. Каждый пытается подогнать трактовку под своё понимание.
Лучше сделать наоборот, идти от проблемы к решению. Проблема является самой важной частью.
Мы описываем проблему, а потом предлагаем решение.
Проблемы и решения SOLID
Нельзя чтобы при изменении одной бизнес фичи перестала работать другая → Ограничиваем код одной бизнес фичей → SRP
Добавление нового не должно требовать переделывания старого → проектируем легко расширяемый код → OCP
Код не должен разваливаться при замене одного компонента на другой → Классы и компоненты с одинаковыми внешними интерфейсами должны быть взаимозаменяемы → LSP
Изменение интерфейса не должно ломать посторонний код → меняя часть интерфейса, мы не должны затронуть код который её не использует → все методы интерфейса должны использоваться → проектируем интерфейсы так, чтобы неиспользуемых частей не было → ISP
Система не должна сломаться от мелких изменений → высокоуровневая абстракция не должна зависеть от деталей → разворачиваем зависимости в обратную сторону (инвертируем зависимости), чтобы детали зависели от абстракций → DIP
Бонус
Полуторачасовое видео, где Роберт Мартин рассказывает о хорошем коде и о SOLID.