Кратко о принципах S.O.L.I.D

Часто в требованиях к разработчику можно заметить пунктик — знание принципов SOLID. Это акроним, объединяющий 5 принципов, которые помогут вам строить гибкие, легко масштабируемые системы, с наименьшим количеством багов либо упрощением их исправления. Это конечно же мечта любого разработчика 🙂

Вы можете найти большее количество ресурсов на эту тему в интернете. Поэтому я не буду сильно разглагольствовать. Лично мне помог разобраться и понять принципы доклад S.O.L.I.D Unity с конференции Unite Austin 2017. Хоть доклад выполнен в рамках конференции Unity, здесь не так уж много сказано о Unity. Как раз наоборот, больше примеров из общей практики. Дэн начинает не по порядку рассказ о принципах, как обычно расшифровывают акроним.  По его мнению, в том порядке в каком он рассказывает легче для понимания.

Я хочу оставить небольшие тезисы по каждому принципу, без приведения и разборов примеров. Мне кажется, в докладе приведены отличные примеры для понимания. Опять же, описание принципов можно легко найти на Википедии…но мне лично нихера не понятно.

Single Responsibility Principle (Принцип единственной ответственности)

  • Один класс – одна ответственность

Если ваш класс выполняет 90% работы приложения, вы где-то cвернули не там.

Open Closed Principle (Принцип открытости/закрытости)

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

Расширяйте классы с помощью дополнительных сущностей! 🙂 Так ваше приложение будет гибким к изменениям.

Liskov’s Substitution Principle (Принцип подстановки Барбары Лисков)

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

Например, у вас есть метод, который принимает базовый класс. В этом случае, метод также без проблем должен работать с потомками класса.

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

  • Используйте интерфейсы, но делайте их направленными на определенные действия

Если интерфейс описывает 5 функций, а вам из них нужно только 2… Не имеет смысла их реализовывать, класс должен знать только то, что ему действительно нужно. Разбейте интерфейс на несколько!  И не забывайте, класс можно реализовывать множество интерфейсов 😉

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

  • Стройте приложение на абстракциях.

Выделяйте абстракции, обобщайте функционал. Интерфейсы идеальны для этого, но абстрактные классы работают тоже 🙂

 

Если вы разобрались с принципами и все поняли — это отлично! Но главное уметь применять их 🙂 Только тонны кода помогут вам увековечить это в памяти.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *