Принципы SOLID - это фундаментальные принципы программирования, которые помогают сохранять код организованным и эффективным. SOLID - это аббревиатура, обозначающая пять принципов объектно-ориентированного программирования. Акроним выглядит следующим образом.
Принцип единой ответственности
Принцип единой ответственности гласит, что у класса должна быть одна и только одна причина для изменения, следовательно, единственная ответственность. Этот принцип включает в себя сплоченность, которая в программной инженерии означает степень взаимосвязи частей функциональности исходного кода в модуле или классе.
Например, предположим, что мы создаем приложение для повышения продуктивности со списком дел, расписанием и таймером. Мы могли бы объединить все наше приложение в один класс, но это было бы не очень хорошо организовано и неэффективно, и мы сгруппировали бы вместе множество частей функциональности, которые сильно отличались бы друг от друга. Вместо этого было бы лучше создать отдельные классы для нашего списка дел, нашего таймера и нашего расписания. Мы будем использовать каждый класс для управления информацией, относящейся к этой области функциональности программы. Мы бы не стали помещать функцию или метод под названием setTimer в класс списка дел, потому что это не самая важная область для этого типа функциональности. Вместо этого эта функция должна принадлежать к классу таймера и иметь большую согласованность с функциональностью в классе таймера.
Принцип открытости / закрытости
Принцип открытости / закрытости гласит, что поведение класса должно иметь возможность расширяться без изменения. Другими словами, класс должен быть открытым для расширения, но закрытым для модификации.
Например, если мы хотим создать программу, которая нашла область формы, мы могли бы начать с создания функции, которая проверяла бы, является ли форма прямоугольником или кругом, а затем определяла бы площадь соответствующим образом. Проблема в том, что если мы хотим найти область другого типа формы, нам нужно будет изменить класс. Согласно принципу открытого / закрытого типа, лучше вместо этого создать отдельный класс для каждого типа формы, укомплектованный собственным методом или функцией для определения площади формы. Это оставит программу открытой для расширения в виде дополнительных классов, создаваемых для расширения функциональности программы, но программа будет закрыта для модификации, потому что существующий код не нужно будет изменять.
Принцип замены Лискова
Принцип замены Лискова гласит, что подтипы должны заменяться их базовыми типами. Мотивация, лежащая в основе этого принципа, состоит в том, чтобы гарантировать, что наследование не используется, когда оно не подходит для кода. Хотя может быть проще расширить класс до подкласса, если функциональные возможности класса не будут использоваться или будут перезаписаны подклассом, наследование не должно использоваться.
Принцип разделения интерфейса
Принцип разделения интерфейсов гласит, что несколько конкретных интерфейсов лучше, чем один общий интерфейс. Этот принцип включает согласованность интерфейсов и преимущества небольшого количества вариантов поведения. Согласно принципу разделения интерфейсов, зависимость одного класса от другого должна быть минимально возможным интерфейсом.
Идея, лежащая в основе принципа разделения интерфейса, заключается в том, что если код реализует интерфейс, он должен использовать все в интерфейсе, и код также не должен полагаться на методы, которые он не использует или к которым не должен иметь доступа. Решением этой проблемы является сохранение небольших размеров интерфейсов, чтобы свести к минимуму взаимозависимость.
Принцип инверсии зависимостей
Принцип инверсии зависимостей состоит из двух частей. Во-первых, модули высокого уровня не должны зависеть от модулей низкого уровня; они оба должны зависеть от абстракций. Во-вторых, абстракции не должны зависеть от деталей, детали должны зависеть от абстракций.
Первая часть этого означает, что модуль высокого уровня не должен выполнять работу низкого уровня. Аналогия заключается в том, что генеральный директор компании не будет осуществлять поставки или принимать звонки в службу поддержки, у него есть собственная работа, связанная с более высоким уровнем. То же самое и с модулями и классами. Возвращаясь к нашему примеру приложения для повышения производительности, класс, который отображает все приложение и его высокоуровневые компоненты списка дел, расписания и таймера, не должен отвечать за установку имени нового события в расписании. Это работа для компонента более низкого уровня в классе расписания.
Вторая часть принципа инверсии зависимостей - использование абстракций над конкретными деталями - помогает сохранить гибкость кода. Чем больше информации жестко запрограммировано в программе и чем больше конкретных деталей используется в коде, тем более жестким становится код и тем более ограниченными могут быть его функциональные возможности и возможности использования. Такое отсутствие гибкости и кода может сделать его подверженным ошибкам и ограниченным или плохим пользовательским интерфейсом.
