SOLID глазами разработчика

Когда мы говорим про ООП, то очень часто мы упоминаем принципы SOLID, которые были сформулированы Робертом С. Мартином. О них говорят и очень часто о принципах спрашивают на собеседованиях. Тем не менее многие разработчики (даже опытные), часто не могут объяснить, что они означают на практике, хотя и могут пересказать каждый из них наизусть.
В данном материале я попытался подойти к этим принципам с практической точки зрения с помощью простых и понятных примеров.
Мы рассмотрим каждый из принципов по отдельности. Рассмотрим его описание, цели и примеры нарушения и следования принципу.

S – Single Responsibility Principle

Описание

Принцип единой ответственности говорит о том, что класс должен иметь одну ответственность.

Цель

Разделить классы таким образом, что “поломка” одной логики не затронет другую логику.

Пример

НарушениеСледование
В команде есть 1 специалист, который выполняет все функции. Если он заболел – рабочий процесс остановленВ команде есть 4 специалиста, каждый из которых отвечает за свой участок. Если один из них заболел – остановится только та, часть процесса, за которую он отвечает. Остальные не будут затронуты.

O – Open/Closed Principle

Описание

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

Цель

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

Пример

НарушениеСледование
Система работает с Redis. После рефакторинга логика работы с Redis удалена и добавлена логика работы с MySQL.Система работает с Redis. После рефакторинга логика работы с Redis неизменна и добавлена логика работы с MySQL.

L – Liskov Substitution Principle

Описание

Принцип подстановки Барбары Лисков говорит о том, что если класс B  является подклассом A, то объекты классы А могут быть заменены объектами класса B, без нарушения работоспособности системы.

Цель

Сделать родительские классы и классы наследники полностью взаимозаменяемыми.

Пример

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

I – Interface Segregation Principle

Описание

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

Цель

Создать такой набор интерфейсов, который позволит классам реализовывать только действительно необходимое поведение.

Пример

НарушениеСледование
Все разработчики обязаны владеть навыками “ТЫЖ_ПРОГРАММИСТА”, что потребует имплементировать для BACK_END_DEV и MOBILE_APP_DEV поведение, которое к ним не относится.Выделены 3 основные группы навыков для BACKE_END, MOBILE_APP и SYSTEM_ADMIN. Это позволит реализовывать только необходимое поведение. И даже когда появится ТЫЖ_ПРОГРАММИСТ, он сможет просто имплементировать все нужные интерфейсы.

D – Dependency Inversion Principle

Описание

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

Цель

Уменьшить связанность системы и сделать верхние уровни системы максимально гибкими при реализации.

Пример

НарушениеСледование
Разработчик умеет писать код только в IDE Net Beans. Т.е. его возможность писать код (абстракция) связана с конкретной IDE (детали). Что делает невозможным легкую замену среды разработки (деталей).Разработчик умеет писать код (абстракция). И в этой абстракции мы никак не связаны со средой разработки (деталями). Что позволяет легко заменить IDE на любую другую, не затронув основное поведение.

Вывод

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