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

Что такое S.O.L.I.D?

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

  • S - принцип единоначалия
  • O - Принцип открытости-закрытости
  • L - принцип подстановки Лискова
  • I - Принцип разделения интерфейсов
  • D - Принцип инверсии зависимостей

История

Принципы SOLID были представлены Робертом Мартином (дядя Боб), американским инженером-программистом, но Майкл Фезерс является представителем аббревиатуры SOLID.

Пять принципов

01. Принцип единственной ответственности

Это принципиальное определение состоит в том, что «у класса должна быть только одна причина для изменения», что означает, что каждый класс должен иметь только одну ответственность. Если мы получим какой-то пример: в процессе разработки программного обеспечения у бизнес-аналитики есть своя работа, они собирают требования от клиента. У программистов есть свои работы, они внедряют программное обеспечение. Таким образом, у каждого есть одна работа или одна ответственность. Иногда программисту приходится добавлять в систему некоторые дополнительные функции и добавлять их в тот же класс. Тогда он должен быть сложным и очень длинным. у нас есть решение этой проблемы, мы разделяем основной класс на подклассы или можем использовать слои для приложения.

02. Принцип открытости-закрытости

Это принципиальное определение состоит в том, что «программные объекты должны быть открыты для расширения, но закрыты для модификации». Это означает, что нам не нужно изменять класс для расширения поведения класса. Пример: есть два разработчика, у разработчика ABC есть класс, и ему нужно что-то сделать с классом. В то же время разработчик CDE может вносить некоторые изменения в тот же класс, но не иметь прямого доступа к классу. Затем предыдущий код и измененный код были разделены, что обеспечивает лучшую стабильность и удобство сопровождения вашего кода.

03. Принцип замещения Лискова

Это принципиальное определение состоит в том, что « подтипы должны заменять свои базовые типы». Это означает, что любой дочерний класс должен иметь возможность использовать вместо родительского дочернего класса без какого-либо неожиданного поведения. Пример: в бургер-шопе есть куриные гамбургеры, и они дают нам несколько вариантов, чтобы добавить в бургер некоторые дополнительные элементы. Можно добавить сыр, помидоры или лук. Куриный бургер - это родительский класс, другие - дочерние классы (сыр, помидор, лук). Они (сыр, помидор, лук) наследуют класс куриных бургеров.

04. Принцип разделения интерфейса

Этот принцип похож на наш первый принцип (принцип единой ответственности). Это принципиальное определение состоит в том, что «не заставляет клиентов реализовывать интерфейс, который им не важен». Это означает, что вам следует использовать множество клиентских интерфейсов, потому что это лучше, чем один интерфейс общего назначения. В качестве примера представьте, что вы собираетесь на супермаркет, чтобы купить мяса. В супермаркете есть специальная зона для хранения мяса, которое вы можете легко купить, иначе вы не сможете легко его найти. Принцип разделения интерфейса помогает нам уменьшить побочные эффекты и сложность.

05. Принцип инверсии зависимостей

Я должен сказать очень важную вещь, прежде чем мы рассмотрим этот принцип. Инверсия зависимостей и внедрение зависимостей - это не похожие концепции. Держите это в уме, потому что большинство людей думают, что это одно и то же.

Этот принцип состоит из двух ключевых компонентов.

  • Абстракции не должны зависеть от деталей.
  • Детали должны зависеть от абстракций.

По указанным выше причинам, если высокий класс будет сильно зависеть от класса низкого уровня, тогда есть причина иметь тесно связанный код или если мы попытаемся изменить один класс, и это приведет к поломке другого класса. Эти ситуации являются риском в реальном мире. Вы можете используйте абстракцию и поддерживайте код как слабо связанный код.

Заключение

Если мы будем использовать принципы S.O.L.I.D, мы сможем легко разработать качественное программное обеспечение, которое легко расширять, надежно и многократно.