SOLID Principles Demystified: Simplifying Software Design
Makar M.Введение
Термин SOLID можно часто встретить в различных статьях о написании качественного кода, а также в вопросах о программной разработке от новичков и в ответах на них от более опытных разработчиков. Если вдруг вы задались вопросом, что такое SOLID или просто хотите узнать для себя что-нибудь новое, то эта серия статей для вас.
Что такое SOLID?
«Хорошая программная система начинается с чистого кода»
(Robert Cecil Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design)
SOLID — это набор принципов проектирования ПО, собранный Робертом Мартином (Robert Cecil Martin), следование которому помогает строить простые и понятные компоненты и модули, терпимые к изменениям, и способные служить основой для других компонентов.
История этой пятёрки принципов берёт своё начало в конце 1980-х годов, когда Роберт Мартин задался идеей их сбора, обсуждая принципы проектирования ПО с пользователями USENET. От первых версий SOLID претерпел большие изменения. В окончательном виде принципы приняли свой вид только в начале 2000-х годов.
Термин SOLID (можно перевести как «прочный», «надёжный», «основательный») является акронимом, предложенным Роберту Мартину, примерно в 2004 году, Майклом Физерсом (Michael Feathers) и полученный путём переупорядочивания изначального набора принципов.
Принципы SOLID
Принципы SOLID описывают, как объединять данные вместе с их поведением в логические сущности (например, классы), а также как эти сущности должны взаимодействовать друг с другом. Однако упоминание слова «класс» не означает, что эти принципы применимы исключительно к объектно-ориентированному программированию. Класс — это лишь инструмент инкапсуляции данных и поведения в нечто одно, который может реализовываться и называться по-разному в зависимости от языка программирования.
SOLID состоит из пяти принципов, сформулированных ниже:
- SRP (Single Responsibility Principle) — принцип единственной ответственности.
Собирайте вместе те вещи, которые изменяются по одним и тем же причинам. Разделяйте те вещи, которые изменяются по разным причинам. - OCP (Open-Closed Principle) — принцип открытости/закрытости.
Модуль должен быть открыт для расширения, но закрыт для модификации. - LSP (Liskov Substitution Principle) — принцип подстановки Барбары Лисков.
Программа, использующая интерфейс, не должна быть сбита с толку реализацией этого интерфейса. - ISP (Interface Segregation Principle) — принцип разделения интерфейсов.
Делайте интерфейсы небольшими, чтобы пользователи не зависели от того, что им не нужно. - DIP (Dependency Inversion Principle) — принцип инверсии зависимости.
Зависимости должны быть направлены в сторону абстракций. Высокоуровневые модули не должны зависеть от низкоуровневых деталей.
Каждый из этих принципов будет подробно рассмотрен с разных сторон в следующих статьях.
Потенциальные проблемы применения SOLID
- Избыточная сложность на небольших проектах.
На небольших или простых проектах попытка строго следовать принципам SOLID может привести к созданию ненужной сложности. Например, чрезмерное разделение классов и интерфейсов делает систему сложной для понимания и сопровождения. Оценивайте масштаб проекта. В небольших приложениях можно применять принципы избирательно, избегая дробления структуры без явной необходимости. - Овердизайн и преждевременная оптимизация.
Стремление реализовать OCP (Open-Closed Principle) или ISP (Interface Segregation Principle) может привести к чрезмерно гибкому дизайну, который пытается предусмотреть все возможные изменения. В результате код становится избыточно сложным и трудным для чтения. Дизайн должен быть эволюционным. Реализуйте гибкость только в тех частях системы, где это действительно необходимо, на основе существующих требований, а не гипотетических сценариев. - Избыточные зависимости.
Следование DIP (Dependency Inversion Principle) может привести к созданию избыточных абстракций и сложной системы зависимостей. Это увеличивает нагрузку на разработчиков, усложняет тестирование и требует дополнительных усилий для поддержки интерфейсов и их реализаций. Упрощайте систему. Создавайте абстракции только там, где они действительно приносят пользу, и ограничивайте глубину иерархии зависимостей. Всегда проверяйте, оправдана ли добавляемая гибкость.
Заключение
Хорошая программная система начинается с чистого кода. Однако добиться чистого кода невозможно, просто слепо следуя перечисленным принципам.
SOLID — это инструмент для анализа, позволяющий взглянуть на код под новым углом и сделать осознанные выводы. Не стоит принимать их на веру — проверяйте, экспериментируйте и, при необходимости, оспаривайте.
Ведь даже из отличных компонентов, построенных на принципах SOLID, можно собрать никуда не годную систему, если не осознавать, как и зачем они используются.