Эти пять принципов разработки программного обеспечения служат руководством для создания программного обеспечения, которое легко масштабировать и поддерживать. Их популяризировал инженер-программист Роберт С. Мартин. В этих принципах изложены передовые методы разработки программного обеспечения с учетом долгосрочного обслуживания и расширения проекта. Принятие этих методов также может помочь вам избежать запахов кода, реструктурировать код и разрабатывать гибкое или адаптивное программное обеспечение. Следовательно, по мере того, как наши приложения растут в размерах, мы можем уменьшить их сложность и избавить себя от головной боли в будущем!
Принципы SOLID состоят из следующих пяти концепций:
- Единаяединая ответственность
- Oперо/закрыто
- Лисков Замена
- Разделение интерфейса
- Dинверсия зависимости
Принцип единой ответственности
"У класса должна быть одна и только одна причина для изменения, то есть у класса должна быть только одна работа."
Как этот принцип помогает нам создавать лучшее программное обеспечение?
Когда у класса много обязанностей, у него больше шансов иметь дефекты, потому что изменение одного из них может повлиять на другие без вашего ведома. Эта идея направлена на то, чтобы разделить поведение, чтобы, если проблемы возникнут в результате ваших изменений, они не повлияли на другое несвязанное поведение.
Принцип открытия/закрытия
"Объекты или сущности должны быть открыты для расширения, но закрыты для модификации"
Это означает, что класс должен быть расширяемым без изменения самого класса. Если вы хотите, чтобы класс выполнял больше функций, идеальным подходом является добавление к уже существующим функциям, а НЕ изменение их.
Этот принцип стремится расширить поведение класса, не влияя на его текущее поведение. Это делается для предотвращения возникновения ошибок везде, где используется класс.
Принцип замены Лисков
"Каждый подкласс/производный класс должен иметь возможность заменить родительский/базовый класс"
Ошибки могут возникать, когда дочерний класс не может выполнять то же поведение, что и его родительский класс.
Когда вы создаете новый класс из существующего, старый становится родительским, а новый — дочерним. Дочерний класс должен иметь возможность выполнять все функции родительского класса. Наследование является термином для этой процедуры.
Дочерний класс должен иметь возможность обрабатывать те же запросы, что и родительский класс, и предоставлять тот же результат или результат того же типа.
Если родительский класс приносит вам кофе (это может быть кофе любого сорта). Поскольку капучино — это особый вид кофе, дочернему классу разрешено давать его, но нельзя приносить воду.
Если детский класс не соответствует этим стандартам, он был полностью изменен и таким образом нарушает эту концепцию.
Этот принцип направлен на то, чтобы родительский класс и его дочерний класс можно было использовать одинаково, не вызывая никаких проблем.
Принцип разделения интерфейсов
"Клиентов нельзя заставлять применять методы, которые они не используют"
Когда класс вынужден выполнять ненужные действия, это расточительно и может привести к непредвиденным ошибкам, если классу не хватает необходимых возможностей.
Должны выполняться только действия, необходимые для выполнения обязанностей Класса. Если какое-либо другое действие, вероятно, будет использовано другим классом в будущем, оно должно быть исключено или перемещено.
Эта идея направлена на то, чтобы разбить набор действий на более мелкие фрагменты, чтобы класс выполнял только те действия, которые ему нужны.
Принцип инверсии зависимостей
"Модули более высокого уровня не должны зависеть от модулей более низкого уровня, но они должны зависеть от абстракций"
В соответствии с этим принципом класс не следует объединять с инструментом, который он использует для выполнения операции. Скорее, его следует объединить с интерфейсом инструмента, чтобы он мог подключаться к классу.
Далее указывается, что ни класс, ни интерфейс не должны знать, как работает инструмент. Однако инструмент должен соответствовать спецификациям интерфейса.
Создавая интерфейс, этот принцип пытается уменьшить зависимость класса высокого уровня от класса низкого уровня.
