Что говорят SOLID принципы?

SOLID — аббревиатура, объединяющая 5 принципов:

S - The Single Responsibility Principle (SRP) - принцип единственности ответственности

Принцип единственности ответственности или принцип единственности обязанности заключается в том, что класс (объект) должен выполнять строго одну задачу, иметь одну зону ответственности. Объект должен выполнять свою задачу очень хорошо, другие объекты не должны отвечать за эту задачу вовсе.

По Дяде Бобу, одна и только одна причина может быть для изменения модуля. Модуль должен отвечать перед одним и только одним актором.

O - The Open Closed Principle (OCP) - принцип октрытости/закрытости

Программные сущности должны быть открыты для расширения, но закрыты для модификации.

Открыты для расширения означает, что новые сущности могут создаваться путём создания новых типов сущностей.

Закрыты для модификации означает, что при расширении сущности не должна быть необходимость изменять код, который работает с этими сущностями.

Мы можем менять сущность делая баг фиксинг или мелкие изменения, но не можем переопределить функцию или создать новую, так как придется менять клиент, где эта сущность вызывается. Чтобы соблюдать OCP, нужно работать через интерфейсы и делать зависимости на основе интерфейсов. Тогда клиенту будет абсолютно все равно на то, что мы начали использовать новую реализацию, потому-что клиент зависит не от сущности напрямую, а от интерфейса. 

L - Liskov substitution - принцип подстановки

Объекты могут быть заменены экземплярами их подтипов (наследниками) без изменения правильности выполнения программы.

I - Interface Segregation Principle - принцип разделения интерфейсов

Лучше иметь множество конкретных интерфейсов, чем один общий.

D - Dependency Inversion Principle - принцип инверсии зависимостей

Абстракции не должны зависеть от деталей реализации. Реализация должна зависеть от абстракций. На практике это означает, что модули верхних уровней не должны зависеть от модулей нижних уровней. Все модули должны зависеть от абстракций.

Есть очень простой пример, позволяющий понять принцип. Например, есть сущность комментарий. Для сохранения комментария нам нужно соединение с базой данных. Так вот, если для сохранения комментария мы будем передавать mysqli_connection или pdo_connection или еще что-то в этом роде - то мы нарушим принцип инверсии зависимостей. Соединение с базой данных - в данном случае модуль низкого уровня. А комменатрий - модуль верхнего уровня. Таким образом для сохранения комментария нам нужно передавать абстрактный коннекшен, то есть интерфейс.

Комментарий не должен напрямую зависить от конкретного соединения, а должен завить от абстрактного DbConnection (это интерфейс). При следовании принципу инверсии зависимостей, если мы поменяем используемую базу данных c MySQL на PostgreSQL или другую, то нам не придется в классе, сохраняющем комментарий, менять реализацию. Комментарий продолжит сохраняться, а мы подменим только реализацию DbConnection.

 
 
 

icon Комментарии 0

Ваш комментарий к статье.. (для авторизованных)

ctrl+enter

icon Вход в систему

зарегистрироваться
НОВЫЕ ПОЛЬЗОВАТЕЛИ