У объектно-ориентированного программирования есть свои принципы, и это не просто превращение всего в объекты и их использование, когда они нам нужны. Важно создавать понятные объекты.
Вопрос №1
Важно ли это? Почему?
Да, это важно и имеет больше смысла, когда приложение растет и становится больше.
Принципы проектирования побуждают нас создавать удобное и гибкое программное обеспечение.
Вопрос 2
Как?
В каждой работе, если у вас есть какие-то принципы и стандарты, ваш проект получит отличную структуру.
Как и при использовании фреймворка, здесь следует следовать некоторым принципам.
Вопрос №3
Итак, что такое SOLID?
- S: принцип единой ответственности
- O: принцип Open/Close
- L: принцип замещения Лисков
- I: принцип разделения интерфейсов
- D: принцип инверсии зависимостей
Вопрос 4
Что они означают?
– S: принцип единой ответственности
У класса должна быть только одна обязанность.
У него должна быть одна причина для изменения.
Преимущества:
Тестирование: лучше класс с меньшим количеством тестовых случаев.
Меньшая связанность: меньшая функциональность в одном классе будет иметь меньше зависимостей.
Организация: меньшие и более хорошо организованные классы лучше чем монолитные. (Например, не создавайте один класс для автомобиля и его функций, создайте два отдельных класса, один для автомобиля и один для функций автомобиля)
– O: Принцип открытия/закрытия
Открыть для расширения, закрыть для модификации.
Нам не разрешено изменять существующие коды классов, потому что это создает новые ошибки.
Например, когда в систему необходимо внедрить новый тип автомобиля, вам следует не изменять класс автомобиля, правильный способ - расширить класс автомобиля.
– L: принцип подстановки Лисков
Класс и его подкласс должны иметь возможность заменять друг друга. Если у вас есть класс автомобиля и гоночного автомобиля, а класс гоночного автомобиля является подклассом класса автомобиля, вы должны иметь возможность изменять или заменять их, не нарушая поведения программы.
– I: Принцип разделения интерфейсов
Большие интерфейсы следует разделить на более мелкие.
Например, ваш интерфейс парикмахера состоит из стрижки, бритья и мытья.
Может случиться так, что вы нанимаете кого-то только для мытья и бритья, а не для стрижки волос. , и он не парикмахер.
Так? Будет действительно лучше, если вы разобьёте его на мелкие кусочки, а не помещать всё в один интерфейс.
– D: принцип инверсии зависимостей
Модули высокого и низкого уровня должны зависеть от абстракции, а не друг от друга. В другой форме класс должен зависеть от абстракции.
