solid-dev-guy

SOLID - это аббревиатура пяти принципов объектно-ориентированного дизайна. Впервые она была сформулирована Робертом Мартином.

Следуя SOLID принципам, ты будешь писать чистый, понятный и поддерживаемый код.

На каком бы языке ты не программировал и какие бы фреймворки не использовал, применяй SOLID принципы каждый день и приобщай к этому коллег.

Что такое SOLID?

Прямой перевод слова solid - жирный. Но это же аббревиатура и чтобы лучше понять ее, начнем с расшифровки каждой буквы на английском языке:

S - Single-responsibility principle (Принцип единственной ответственности)
O - Open-closed principle (Принцип открытости-закрытости)
L - Liskov substitution principle (Принцип подстановки Барбары Лисков)
I - Interface segregation principle (Принцип разделения интерфейсов)
D - Dependency inversion principle (Принцип инверсии зависимостей)

Принцип единственной ответственности (SRP)

Класс должен делать только одно дело и делать его хорошо. У класса должна быть только одна причина для изменений.

Ты можешь применить этот принцип более широко. Функции, переменные, модули. Следуй принципу единственной ответственности и не пробуй запихнуть все что тебе приходить в голову в один класс.

Принцип открытости-закрытости (OCP)

Классы должны быть открыты для расширения, но закрыты для изменения.

На первый взгляд, нет ничего страшного в изменении. Все когда-то меняется.

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

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

Если у тебя не получилось разобраться с принципом единственной ответственности, то и тут возникнут проблемы.

Принцип подстановки Барбары Лисков (LSP)

Объекты дочерних классов должны иметь возможность без проблем использоваться везде, где используются объекты класса родителя.

Простыми словами, это значит, что если у тебя есть класс Dog, который умеет делать bark(), то будет неправильно создавать MechanicalDog, которая расширяет Dog, но будет лаять только если ей дадут батарейки, а без них бросит исключение.

Принцип разделения интерфейсов (ISP)

Клиенты не должны зависеть от методов, которые они не используют.

Ты можешь рассматривать этот принцип, как SRP (принцип единственной ответственности) для интерфейсов.

Разгребай завалы и убедись, что в твоих интерфейсах нет лишних функций.

А если найдешь такие — раздели один интерфейс на два, три, или сколько будет нужно.

Принцип инверсии зависимостей (DIP)

Модули верхних уровней не должны зависеть от модулей нижних уровней. Все они должны зависеть от абстракций (интерфейсов).

Кажется очевидным? Присмотрись и ты увидишь нарушение принципа инверсии зависимостей на каждом шагу.

Вывод

Принципы SOLID могут казаться простыми, очевидными или лишними. Но попробуй начать применять их уже сегодня и обрати внимания, что ты уже не можешь не замечать косяки своих коллег.

P.S. О, и помни об Agile подходе.

Код должен работать → Код быть красивым → Код должен быть быстрым

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