| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| php_patterns_solid [2021/08/25 19:46] – chifek | php_patterns_solid [2023/09/14 06:06] (current) – external edit 127.0.0.1 |
|---|
| |
| Роберт Мартин в 1996-м дал другое определение, более понятное: | Роберт Мартин в 1996-м дал другое определение, более понятное: |
| Функции, использующие указатели ссылок на базовые классы, должны уметь использовать объекты производных классов, даже не зная об этом. | |
| | ''Функции, использующие указатели ссылок на базовые классы, должны уметь использовать объекты производных классов, даже не зная об этом.'' |
| Попросту говоря: подкласс/производный класс должен быть взаимозаменяем с базовым/родительским классом. | Попросту говоря: подкласс/производный класс должен быть взаимозаменяем с базовым/родительским классом. |
| |
| Значит, любая реализация абстракции (интерфейса) должна быть взаимозаменяемой в любом месте, в котором принимается эта абстракция. По сути, когда мы используем в коде интерфейсы, то используем контракт не только по входным данным, принимаемым интерфейсом, но и по выходным данным, возвращаемым разными классами, реализующими этот интерфейс. В обоих случаях данные должны быть одного типа. | Значит, любая реализация абстракции (интерфейса) должна быть взаимозаменяемой в любом месте, в котором принимается эта абстракция. По сути, когда мы используем в коде интерфейсы, то используем контракт не только по входным данным, принимаемым интерфейсом, но и по выходным данным, возвращаемым разными классами, реализующими этот интерфейс. В обоих случаях данные должны быть одного типа. |
| | |
| | ===== Принцип разделения интерфейса (Interface Segregation Principle) ===== |
| | |
| | ''Нельзя заставлять клиента реализовать интерфейс, которым он не пользуется.'' |
| | |
| | Это означает, что нужно разбивать интерфейсы на более мелкие, лучше удовлетворяющие конкретным потребностям клиентов. |
| | |
| | Как и в случае с принципом единственной ответственности, цель принципа разделения интерфейса заключается в минимизации побочных эффектов и повторов за счёт разделения ПО на независимые части. |
| | |
| | |
| | ===== Принцип инверсии зависимостей (Dependency Inversion Principle) ===== |
| | |
| | ''Высокоуровневые модули не должны зависеть от низкоуровневых. Оба вида модулей должны зависеть от абстракций.'' |
| | |
| | ''Абстракции не должны зависеть от подробностей. Подробности должны зависеть от абстракций.'' |
| | |
| | Проще говоря: зависьте от абстракций, а не от чего-то конкретного. |
| | |
| | Применяя этот принцип, одни модули можно легко заменять другими, всего лишь меняя модуль зависимости, и тогда никакие перемены в низкоуровневом модуле не повлияют на высокоуровневый. |
| | |
| | |
| | |
| | ===== Ссылки ===== |
| | |
| | [[https://habr.com/ru/company/mailru/blog/412699/]] |
| |