SOLID¶
«Непосредственное ознакомление с источниками и внимание к голосу самой древности, несомненно, глубже введет читателя в её таинственный мир, чем всякого рода изложения и описания, как бы талантливы они ни были».
И. М. Волков, «Законы вавилонского царя Хаммурапи».
SOLID — название методики и акроним для пяти основных принципов проектирования программного обеспечения на базе объектно-ориентированного подхода. Как и применение других архитектурных принципов, применение SOLID помогает поддерживать и модернизировать код.
SRP
Single-responsibility principle, принцип единственной ответственности.
Окончательная версия SRP формулируется как «Модуль должен отвечать за одного и только за одного актора»; сам Роберт Мартин считал SRP несколько трудным для понимания, но на мой взгляд, всё достаточно сильно упрощается, если вместо «акторов» использовать термин «группа лиц». Тогда сразу становится понятно, что «актор» — это не какие-то взаимосвязанные классы или иные программные сущности, а всего лишь люди, пользователи, в интересах которых и проводится разработка программы. Соответственно, класс должен отвечать за удовлетворение запросов только одной группы лиц.
Если еще больше упростить формулировку, то можно даже сказать, что класс должен отвечать за интересы только одного отдела. Соответственно, если класс реализует функционал, необходимый одновременно и бухгалтерии, и снабженцам или, например, и конструкторам, и технологам - такой класс нужно переписать, разделив на два.
OCP
Open–closed principle, принцип открытости/закрытости.
Классы должны быть закрыты от изменения своих существующих внешних свойств (чтобы вызывающий код, опирающийся на эти классы, не нуждался в обновлении), но в то же время открыты для расширения и добавления новых методов и нового поведения. Иначе говоря, при изменении существующих методов класса код можно менять только таким образом, чтобы внешнее поведение класса оставалось неизменным.
LSP
Liskov substitution principle, принцип подстановки Барбары Лисков.
Принцип, декларирующий правила изменения функционала при наследовании. Код, использующий переменную базового класса, не должен замечать никакой разницы, если ему «подсунуть» переменную наследующих классов. Или, иначе говоря, класс-наследник не имеет права требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше возможностей, чем базовый класс.
ISP
Interface segregation principle, принцип разделения интерфейсов.
Реализация интерфейса не должна иметь дела с неиспользуемыми методами. В соответствии с ISP рекомендуется создавать минималистичные интерфейсы, без «запасных» методов, содержащие минимально необходимое и достаточное количество специфичных методов, все из которых необходимы при создании реализации. Если реализация интерфейса не пользуется каким-либо методом интерфейса, то лучше создать новый интерфейс, без этого метода.
Несоблюдение принципа ISP приведет к тому, что при изменении интерфейса, содержащего «лишние» или «запасные» методы, вам придется корректировать код конкретных реализаций несмотря на то, что он в этих методах совершенно не нуждается и их не использует.
DIP
Dependency inversion principle, принцип инверсии зависимостей.
DIP, как и вообще принцип инверсии управления (Inversion of Control, IoC) — один из столпов чистой архитектуры. Модули верхнего уровня не должны обращаться к модулям нижнего уровня напрямую, между ними должна быть «прокладка» из абстракций (т. е. интерфейсов).
Два важных правила DIP:
интерфейсы не должны зависеть от конкретных реализаций, наоборот, реализации должны зависеть от интерфейсов, т. е. вы сначала должны спроектировать интерфейсы и только потом работать над конкретными методами;
интерфейсы должны быть стабильными; реализации можно менять часто, но сами интерфейсы желательно корректировать как можно реже.
codifycamera.com © Авторские права CC BY-NC-SA 4.0 2024 — ∞ Михаил Емельянов, war4one@gmail.com