Привет, дорогой читатель! Сегодня мы собираемся отправиться в путешествие в мир разработки программного обеспечения. Но не волнуйтесь, мы не будем углубляться в какой-либо код. Вместо этого мы будем изучать принципы SOLID, набор рекомендаций, которые разработчики используют для написания лучшего кода.
Думайте об этих принципах как о «золотых правилах» программирования.
Давайте разберем эти принципы так, чтобы их поняла даже моя бабушка, а она до сих пор пользуется телефоном-раскладушкой!
S — Принцип единой ответственности (SRP)
Представьте, что вы на вечеринке, и есть один друг, который пытается сделать все. Они готовят, подают напитки, развлекают гостей и одновременно пытаются диджеить. Это катастрофа, верно? Еда подгорела, напитки разбавлены, гости скучают, а музыка… не будем даже туда заходить.
В программировании принцип единственной ответственности — это идея о том, что класс (схема создания объекта в программировании) должен иметь только одно задание. Как и наш чрезмерно усердный друг, класс, который пытается справиться со слишком большим количеством задач, скорее всего, все испортит.
O — Принцип открытия-закрытия (OCP)
Допустим, вы купили новую машину. Он идеален во всех отношениях, кроме одного — у него нет люка. Теперь вы можете взять бензопилу и вырезать дыру в крыше, но это, вероятно, приведет к аннулированию гарантии (и попаданию под дождь).
Принцип открытого-закрытого аналогичен. Код должен быть «открытым» для расширения (например, добавление люка на крыше), но «закрытым» для модификации (бензопилы не нужны!). Это означает, что мы должны иметь возможность добавлять новые функции или функции без изменения существующего кода.
L — Принцип замещения Лисков (LSP)
Представьте, что вы играете в футбол, и вдруг кто-то решает заменить футбольный мяч шаром для боулинга. Это все еще мяч, верно? Ну, вы можете попытаться пнуть его, но вы, вероятно, сломаете ногу.
Принцип подстановки Лисков гласит, что в нашем коде любой дочерний класс должен иметь возможность заменить свой родительский класс без того, чтобы программа взорвалась (или сломала вам ногу). Другими словами, если пингвин (дочерний класс) не может летать, он не должен быть подтипом птицы (родительский класс) в нашей программе.
I — Принцип разделения интерфейсов (ISP)
Вернемся к сценарию вечеринки. На этот раз у вас есть друг-вегетарианец. Не могли бы вы предложить им комбинированное блюдо «Барбекю из курицы и стейка»? Конечно, нет! У них должно быть собственное меню на выбор.
Точно так же принцип разделения интерфейсов предполагает, что мы не должны заставлять класс зависеть от интерфейсов (контракт для класса), которые он не использует. Это как дать нашему другу-вегетарианцу собственное вкусное меню, чтобы ему не пришлось пропускать половину блюд.
D — Принцип инверсии зависимостей (DIP)
Наконец, представьте, что вы строите дом из LEGO. Вы же не стали бы приклеивать каждую деталь непосредственно к следующей, не так ли? Конечно, нет! Вы хотите иметь возможность поменять красный кирпич на синий, если передумаете.
Принцип инверсии зависимостей — это LEGO наших принципов SOLID. Модули высокого уровня (общая форма дома LEGO) не должны зависеть от модулей низкого уровня (отдельных кирпичиков). И то, и другое должно зависеть от абстракций (выпуклостей и отверстий, которые позволяют кирпичам соединяться). Таким образом, мы можем легко заменить части нашего кода, не снося весь дом.
И вот оно! Принципы разработки программного обеспечения SOLID, объясненные таким образом, что не требуется степень в области компьютерных наук. Так что в следующий раз, когда вы услышите, как некоторые разработчики говорят о Liskov или Dependency Inversion, вы можете вставить свои пять копеек. По крайней мере, вы не будете выглядеть оленем в свете фар. Удачного кодирования (или нет)!
