Найти в Дзене

SOLID-принципы на практике: как не писать монолитный код?

В мире разработки программного обеспечения часто можно услышать термин "монолитный код". Это страшный сон любого разработчика: когда кодовая база разрастается до такой степени, что становится сложно поддерживать, тестировать и развивать проект. Чтобы избежать этого кошмара, существуют проверенные принципы проектирования, известные как SOLID. В этой статье мы разберем, как применять эти принципы на практике и писать более поддерживаемый и чистый код.
Что такое SOLID? SOLID — это акроним из пяти принципов объектно-ориентированного программирования, предложенных Робертом Мартином (также известным как Uncle Bob). Каждый из этих принципов помогает сделать код более устойчивым к изменениям и уменьшить связанность компонентов в приложении. Вот краткое описание каждого из них: Теперь давайте рассмотрим каждый принцип более подробно и покажем, как их применять в реальной разработке.
Принцип единственной ответственности (SRP) Этот принцип гласит, что каждый класс должен иметь одну-единст
Оглавление

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

Что такое SOLID?

SOLID — это акроним из пяти принципов объектно-ориентированного программирования, предложенных Робертом Мартином (также известным как Uncle Bob). Каждый из этих принципов помогает сделать код более устойчивым к изменениям и уменьшить связанность компонентов в приложении. Вот краткое описание каждого из них:

  1. Single Responsibility Principle (SRP) — Принцип единственной ответственности.
  2. Open/Closed Principle (OCP) — Принцип открытости/закрытости.
  3. Liskov Substitution Principle (LSP) — Принцип подстановки Барбары Лисков.
  4. Interface Segregation Principle (ISP) — Принцип разделения интерфейсов.
  5. Dependency Inversion Principle (DIP) — Принцип инверсии зависимостей.

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

Принцип единственной ответственности (SRP)

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

Пример нарушения SRP:

-2

В этом случае OrderService выполняет две задачи: создает заказ и отправляет подтверждение по email. Это нарушение принципа SRP.

Как исправить?

Разделим обязанности на два класса:

-3

Теперь каждый класс имеет свою четкую ответственность.

Принцип открытости/закрытости (OCP)

Классы должны быть открыты для расширения, но закрыты для изменения. Это означает, что вы должны иметь возможность добавлять новый функционал, не изменяя существующий код.

Пример нарушения OCP:

-4

Каждый раз, когда добавляется новый способ оплаты, придется изменять существующий код.

Как исправить?

Используем полиморфизм:

-5

Теперь, чтобы добавить новый способ оплаты, достаточно создать новый класс, реализующий интерфейс PaymentMethod.

Принцип подстановки Барбары Лисков (LSP)

Объекты наследуемых классов должны быть взаимозаменяемы с объектами базового класса.

Пример нарушения LSP:

-6

Класс Square нарушает поведение, ожидаемое от базового класса Rectangle, так как изменение ширины или высоты квадрата влияет на оба измерения.

Как исправить?

Используем интерфейсы вместо наследования:

-7

Теперь оба класса реализуют общий интерфейс Shape и не нарушают LSP.

Принцип разделения интерфейсов (ISP)

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

Пример нарушения ISP:

-8

Здесь робот вынужден реализовывать метод eat(), который ему не нужен.

Как исправить?

Разделим интерфейс на два узкоспециализированных:

-9

Теперь классы реализуют только те интерфейсы, которые им действительно нужны.

Принцип инверсии зависимостей (DIP)

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

Пример нарушения DIP:

-10

В этом примере Switch зависит от конкретного класса Light.

Как исправить?

Используем абстракцию:

-11

Теперь Switch может работать с любым устройством, реализующим интерфейс Switchable, будь то свет или вентилятор. Это делает код более гибким и легким для расширения.

Заключение

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