Концепции программирования легко понять, если объяснять их не как код, а как отражение реального мира и того, как мы принимаем решения. Моя попытка здесь такая же. Давайте перейдем прямо к этому, но сначала предпосылка. SOLID.

Принцип SOLID — краеугольный камень хорошего кода.
Так что же такое SOLID?

SOLID — это аббревиатура для другого набора принципов, которые следует учитывать при программировании.
S означает принцип единой ответственности
O означает принцип Open Closed Principle
L означает принцип замещения Лисков
I означает принцип разделения интерфейса
D означает принцип инверсии зависимостей

Теперь давайте углубимся в каждый из этих принципов на примере из реальной жизни.

Принцип единой ответственности. У каждого класса должна быть только одна причина для изменения.

Вы не можете попросить разработчика программного обеспечения в компании быть также менеджером по персоналу. Хотя это сэкономит вам деньги на зарплату HR, есть вероятность, что он/она может испортить ваш процесс найма и адаптации. Этим занимаются программисты. Чтобы сэкономить свое время и объем кода, они возлагают всю ответственность на одного класса.
Теперь в стартапе вы можете брать на себя разные роли под одним и тем же названием, и это прагматично, но если вы многонациональная корпорация, вам готовите себя к падению. Если ваша кодовая база мала, вероятно, вы не столкнетесь с какими-либо проблемами, но такой код не масштабируется.
Второе, что неправильно понимают программисты, — использовать этот принцип как слова из Библии и злоупотреблять им. Новый класс для каждого нового метода. Это также делает код довольно большим и сложным. Вы должны понимать, что даже если программист не HR, он все равно должен разрабатывать, проверять и отлаживать свой код. Вы не можете сделать должностную инструкцию для каждой задачи.

Принцип открытия и закрытия: программныеобъекты (классы, модули, функции и т. д.) должны быть открыты для расширения, но закрыты для модификации.

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

Принцип подстановки Лискова: Oобъекты суперкласса должны быть заменяемы объектами его подклассов без нарушения работы приложения.

Допустим, у вас есть машина. Есть устаревший медиаплеер для компакт-дисков, и теперь вам нужно заменить его на новый медиаплеер с Bluetooth и USB. Интерфейс должен быть таким же, как и старый для подключения к вашему плееру, иначе он не будет работать. Более или менее, это отраслевой стандарт, который обеспечивает такую ​​простоту использования. Аналогично, если вы получаете суперкласс, тогда ваш подкласс должен реализовать функцию таким образом, чтобы контракт функции оставался прежним, и вы не накладывали дополнительных ограничений на тип данных. Вы также должны уберечь себя от создания функций, которые являются фиктивными контрактами. Скорее вы должны сосредоточиться на том, чтобы сделать интерфейс тонким.

Принцип разделения интерфейсов. Клиенты не должны зависеть от интерфейсов, которые они не используют.

Есть приложения, предустановленные в ОС, которые вы никогда не будете использовать. Теперь, если вы не используете эти приложения и каждый раз, когда есть патч безопасности для этих приложений, и вы решаете не получать их, так как вы их не используете, но поставщик угрожает отменить вашу лицензию, потому что вы не обновляете свою ОС! !. Звучит обескураживающе!! Хорошо, тогда не повторяйте в своем коде.
Не раздувайте свои интерфейсы, потому что если есть много классов, которые являются производными от него. Даже если вы хотите изменить подпись в одном классе, вы должны изменить ее в классе, который просто имеет фиктивную реализацию этих функций.

Принцип внедрения зависимостей: Модули более высокого уровня должны зависеть от модулей более низкого уровня. Оба должны зависеть от абстракции. Абстракция не должна зависеть от деталей. Детали должны зависеть от абстракции

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

Я надеюсь, что с помощью этих примеров вы сможете получить более широкое представление о том, как использовать SOLID при программировании. Удачного кодирования!