Когда мы говорим про ООП, то очень часто мы упоминаем принципы 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 с помощью наглядных примеров. Я намерено не приводил примеры кода, так как убежден, что понимание базовых принципов и концепций играет наиважнейшую при разработке ПО.