SOLID — не только имя героя серии Metal Gear, но и аббревиатура, обозначающая 5 основных принципов проектирования в ООП. Давайте узнаем, какие принципы в ней зашифрованы и как в процессе разработки реализовать эти принципы.
Аббревиатура SOLID расшифровывается следующим образом:
S: Принцип единственной обязанности
Каждому классу соответствует только одна обязанность. Если класс решает больше одной задачи, это приводит к тому, что подсистемы, реализующие эти задачи, оказываются зависимы друг от друга. Изменения в одной непременно вызовут изменения в другой или нескольких остальных.
Как реализовать этот принцип в разработке?
Объединять компоненты, которые могут измениться по одной и той же причине. Если компоненты неоднородны и изменения в которых вызываются разными причинами, постарайтесь их не объединять.
O: Принцип открытости-закрытости
Сущности должны быть открыты для расширения, но закрыты для модификаций.
Звучит сложно, не так ли? Однако этот принцип можно выразить иначе: поведение сущности (модулей, классов и пр.) можно изменить, создав новый тип или подтип сущности, однако это не должно вызывать изменений в коде.
L: Принцип подстановки Барбары Лисков
Подклассы должны быть способны заменять родительские классы. Иными словами, проектировать приложение стоит так, чтобы можно было использовать классы-наследники вместо родительских, не причиняя вреда работе приложения.
I: Принцип разделения интерфейса
Разрабатывайте узкоспециализированные интерфейсы, чтобы не обременять пользователя функциями, которые он не будет использовать.
Вместо того, чтобы создать один тяжелый типовой интерфейс, универсальный для всех типов пользователей, разбейте его на специализированные интерфейсы помельче. Пользователи должны видеть только то, что соответствует их задачам.
D: Принцип инверсии зависимостей
Этот принцип может показаться сложным для понимания, так как состоит из 3 частей, однако на самом деле все не так уж и запутанно:
Модули верхних уровней должны быть независимы от модулей нижних.
Оба типа модулей должны зависеть от абстракций.
Детали должны зависеть от абстракций, а не наоборот.
Рано или поздно приложение или ПО вырастает и выходит за границы единственного модуля, а вы начинаете выстраивать зависимости между компонентами. При проектировании можно допустить досадную ошибку, и выйдет так, что высокоуровневый компонент зависит от низкоуровнего. Соответственно, при изменениях в низкоуровневых компонентах, вам придется перебирать и высокоуровневые.
Вам может показаться, что соблюдать каждый из 5 предложенных концепцией принципов будет крайне сложно. Однако для этого вам понадобится только два компонента: стремление и внимательность. Соблюдая SOLID, вы заметите, как улучшилось качество разрабатываемых вами приложений и упростилось их администрирование и поддержка.
Понравилась статья? Тогда ставьте лайк и подписывайтесь на канал, чтобы не пропускать новые выпуски!