SOLID — это очень популярный набор шаблонов проектирования, которые разработчики используют при разработке объектно-ориентированного программного обеспечения. Само название SOLID означает пять принципов дизайна. Они есть,
· Единая ответственность
· Открыто закрыто
· Замена Лискова
· Разделение интерфейса
· Инверсия зависимостей.
С этого момента давайте поговорим о каждом из них.
Единая ответственность
Основная идея принципа единой ответственности: «У класса должна быть одна причина для изменения». Это означает, что класс должен иметь уникальную функциональность или ответственность. Таким образом, будет легко поддерживать наш код как для нас, так и для других. Следуя принципу единой ответственности, он сделает реализацию,
· Легче понять
· Помочь предотвратить ошибки в изменениях
· Более гибкий
· Легче проверить
Мы можем применить этот принцип не только к классам, но и к функциям, программным компонентам, API и т.д.
Если мы рассмотрим приведенный выше пример, мы увидим, что для клиента есть два метода. Хотя метод приветствия связан с клиентом, метод validateCard является еще одной обязанностью клиента. Следовательно, любые изменения в validateCard могут привести к изменению клиента. Правильный способ сделать это — передать ответственность validateCard другому классу.
В качестве приведенных двух примеров мы можем создать еще один класс для проверки карты. Теперь любые изменения в методе проверки не повлияют на клиента.
Открыть-закрыть
Основная идея принципа открытия-закрытия заключается в том, что «классы, модули или любой программный объект должны быть открыты для расширения, но должны быть закрыты для модификации». Другими словами, помимо изменения класса, мы можем просто расширить класс, чтобы внести необходимые изменения. В противном случае он может допустить ошибки в реализации. С помощью этого принципа в качестве преимуществ можно отметить,
· Более ремонтопригодный
· Долговечность приложения
· Минимизируйте риск при добавлении нового поведения
· Менее подвержен ошибкам для существующей реализации
В приведенном ниже примере допустим, что нам нужно рассчитать скидку в соответствии с платежами и скидками. Но в любом случае, как нам нужно рассчитать скидку для VIP-клиента, нам нужно использовать и VIP-скидку.
Поэтому в этом случае мы можем создать еще один класс для vipCustomers и выполнить необходимые реализации, как указано ниже. Итак, внутри созданного нами нового класса мы можем получить vipDiscount и переопределить метод getDiscount в новом классе.
Замена Лисков
Принцип гласит, что каждый подкласс должен иметь возможность заменить свой родительский класс. Этот принцип подобен расширению принципа открытого-закрытого. В более простом смысле дочерний класс должен содержать функциональные возможности родительского класса, но не иметь поведения, отличного от функциональных возможностей или методов родительского класса. Используя этот принцип, мы можем найти некоторые преимущества, например,
· Простота обслуживания
· Повторное использование кода
В качестве недостатков можно отметить,
· Создавайте ненужные запутывания
· Низкая производительность
· Более подвержен ошибкам
· Сложная ремонтопригодность
Как мы видим в данном примере, мы не можем расширить методы класса клиента на класс официанта. Но мы можем создать еще один класс для VIP-клиента и расширить методы. Это означает, что базовый класс не следует расширять, если дочерний класс не может принимать методы своего родительского класса.
Разделение интерфейсов
Основная идея заключается в том, что «клиента нельзя заставлять внедрять методы, которые он не использует». В соответствии с этим принципом будет лучше, если вы сможете использовать более специфические интерфейсы, чем использовать их в регулярно используемых интерфейсах общего назначения. Так что мы можем использовать определенные интерфейсы, а не использовать один раз больше. Таким образом,
· Мы можем уменьшить сложность
· Мы можем повысить ремонтопригодность
Увеличьте читабельность
В приведенном выше примере вы можете увидеть реализацию интерфейса на машинописном языке. Итак, мы можем создать интерфейс newCustomer и реализовать его в классе Vip customer.
Принцип инверсии зависимостей
Основная идея заключается в том, что «модули высокого уровня, обеспечивающие сложную логику, должны легко использоваться повторно и не должны подвергаться изменениям в модулях низкого уровня, предоставляющих служебные функции». Другими словами, это означает, что модули высокого уровня не должны зависеть от модулей более низкого уровня, поэтому мы должны использовать абстракцию и интерфейсы. Чтобы мы могли иметь больше,
· Гибкий
· Многоразовый
Выполнение.
В приведенном выше сценарии мы предоставляем службу внутри конструктора. Итак, у нас есть проблема, что модули высокого уровня зависят от модулей низкого уровня. Чтобы решить эту проблему, мы можем изменить класс CustomerController, чтобы он ссылался только на абстракцию класса службы. Пример приведен ниже.
