Принципы SOLID – это стандарты объектно-ориентированного программирования, которые нужны для построения хорошей архитектуры программы. Каждый ООП-программист должен понимать принципы SOLID, так как они помогают создавать расширяемый, логичный и читабельный код. Причем не важен язык программирования, потому что придерживаться SOLID можно на любом языке, поддерживающем парадигму объектно-ориентированного программирования. Принципы SOLID – это не какой-то паттерн, который можно быстро изучить и быстро внедрить. Они представляют собой свод правил, который можно внедрять постепенно, осваивая ООП.
ООП постоянно приносит в свою парадигму новые подходы к разработке программного обеспечения. В ООП программисты не ограничиваются одним подходом, очень часто происходит различная комбинация. ООП предполагает более строгие правила в программировании, при этом разработчики не застрахованы в конечном счете получить запутанный и непонятный программный код. Чтобы этого не происходило, были придуманы 5 принципов ООП, которые представляют собой концепцию принципов SOLID.
Принципы SOLID
SOLID – это акроним, аббревиатура или «первые буквы» принципов. Расшифровывается так:
«S» – «Single Responsibility Principle», что переводится как «принцип единственной ответственности».
«O» – «Open-Closed Principle», что переводится как «принцип открытия-закрытия».
«L» – «Liskov Substitution Principle», что переводится как «принцип замещения от Барбары Лисков».
«I» – «Interface Segregation Principle», что переводится как «принцип интерфейсного разделения».
«D» – «Dependency Inversion Principle», что переводится как «принцип инверсионной зависимости».
Сейчас рассмотрим все принципы SOLID немного подробнее.
Принцип единственной ответственности
Эта концепция декларирует следующую идею: каждый отдельный класс должен нести ответственность за что-то единое. Потому что, когда класс несет ответственность за разрешение нескольких задач, тогда вокруг класса образуется «подсистема». Если что-то изменить в данной подсистеме, то эти изменения отразятся на всей подсистеме.
Следуя этому принципу, не нужно формировать сложные классы. Если такие классы сформированы, тогда необходимо их декомпозировать в более простые классы. Простейший класс, который отвечает только за что-то свое, легче сопровождать и модифицировать, чем сложные классы. В сложных классах, для того чтобы что-то изменить, придется тратить время на «распутывание» всех взаимосвязей.
Однако следовать этому принципу нужно умеренно, потому не исключено возникновение такой ситуации, когда слишком развитая декомпозиция классов только усложнит код разрабатываемой программы.
Принцип открытия-закрытия
Эта концепция декларирует простейшую идею о взаимоотношении с сущностями: класс, объект, модуль или функция обязаны всегда открываться для масштабирования собственных возможностей, но в то же время закрываться для внесения корректировок. Таким образом, каждая сущность сможет видоизменять собственные возможности, но при этом не видоизменять собственный исходный код.
На первый взгляд этот принцип выглядит немного противоречивым, потому что не сразу возникает понимание каким образом придать сущности новое поведение, не изменяя ее исходного кода. Ответ лежит на поверхности – нужно добавлять новый код. То есть, если изначально вы создали код, который надежно работает, но спустя время вам нужно добавить новый функционал, тогда вы не меняете первоначальный код. Новая функциональность добавляется при использовании наследования, интерфейсов и полиморфизма.
Принцип замещения от Барбары Лисков
Эта концепция декларирует такую идею: каждая функция, которая использует базовый тип, должна иметь возможность использовать подтип базового типа, не ведая об этом. По сути, этот принцип помогает реализовать правильную иерархию наследования типов. То есть, когда базовый тип реализует какое-то изменение, тогда это изменение должно правильно реализоваться и у всех его наследников. Таким образом наследник типа будет дополнять поведение базового типа. При этом, если базовый тип программы заменить на его наследника, тогда в программе не должно возникнуть никаких проблем.
Таким образом этот концепция SOLID гарантирует, что каждый подкласс, созданный программистом, будет правильно взаимодействовать с уже реализованными инструментами, которые работали с его родителем.
Принцип интерфейсного разделения
Эта концепция декларирует такую идею: клиент не должен иметь зависимость от методов интерфейса, которые он не использует при взаимодействии с программой. Таким образом, когда нужно видоизменить неиспользуемый метод, не должна возникать необходимость вносить корректировки в клиентский код.
Этот принцип предполагает, что необходимо создавать специфичные интерфейсы, которые требуют минимальную реализацию различных методов. Избыточный интерфейс – это большое количество ненужных методов, зачастую которые даже не имеют смысла использования их в контексте какого-то класса.
Если интерфейс становится сложным, потому что обрастает разными методами, тогда имеет смысл провести его декомпозицию и создать несколько простых интерфейсов. Простыми интерфейсам легче управлять.
Принцип инверсионной зависимости
Эта концепция декларирует следующую идею:
модули верхнего уровня не должны иметь зависимость от модулей нижнего уровня;
модули верхнего и нижнего уровня должны иметь зависимость от абстракций;
абстракции не должны иметь зависимость от деталей;
детали, как и модули, должны иметь зависимость от абстракций.
Другими словами, этот принцип декларирует идею, что нужно выстраивать компоненты высокого уровня без зависимостей от компонентов низкого уровня. Таким образом, зависимости формируются не на уровне компонентов, а на уровне абстракций. Такой подход облегчает дальнейшее взаимодействие с ними.
Заключение
Сегодня мы разобрали теоретическую часть темы «Принципы SOLID». По теории не должно возникнуть проблем, что касается практической части, то это мы разберем в следующих статьях.
Принципы SOLID требуют умеренного и «не фанатичного» следования им. Потому что если все делать строго по принципам, ситуация в программе может сильно усложниться. Поэтому нарушение этих принципом иногда может быть оправдано и логично, так как принципы SOLID – это не догма.
Другое
