Принципы SOLID: глубокое погружение

SOLID — это аббревиатура пяти принципов объектно-ориентированного проектирования, введённых Робертом Мартином в начале 2000-х. Каждый принцип адресует конкретный сбой проектирования — симптомы, которые вы узнаёте в реальных кодовых базах: классы, которые невозможно расширить, модули, ломающиеся в неожиданных местах при изменении, код, который нельзя протестировать изолированно. Принципы SOLID — это не правила для механического применения, а линзы для выявления проблем проектирования и направления рефакторинга. В этом уроке каждый принцип разобран точно: сначала нарушение, затем исправление, затем архитектурные последствия.

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

S — Принцип единственной ответственности

Формулировка Мартина: «У класса должна быть только одна причина для изменения». Ключевое слово — «причина»: оно относится к актору или стейкхолдеру, чьи требования могут вызвать изменение, а не к синтаксическому правилу «один метод». Класс, который форматирует отчёты И сохраняет их в базу данных, имеет две причины для изменения: команда по отчётности (изменение формата) и команда эксплуатации (миграция базы данных). Когда эти изменения происходят одновременно, они конфликтуют. SRP говорит: эти задачи относятся к разным классам.

Нажмите на подсвеченные строки, чтобы понять нарушение SRP и исправление

java

// ── НАРУШЕНИЕ: две причины для изменения в одном классе ─────────

class OrderProcessor {

▼

  void process(Order order) {

    // бизнес-логика

    order.setStatus(CONFIRMED);

    // сохранение — причина #2 для изменения

    db.save(order);

    // уведомление — причина #3 для изменения

    emailClient.send(order.getEmail(), buildШаблон(order));

// ── ИСПРАВЛЕНИЕ: у каждого класса одна причина для изменения ────

class OrderConfirmationService {

▼

  OrderConfirmationService(OrderRepository repo, OrderNotificationService notifier) { ... }

  void confirm(Order order) {

    order.confirm();          // только доменная логика

    repo.save(order);         // делегирует сохранение

    notifier.sendConfirmation(order); // делегирует уведомление

class OrderRepository      { void save(Order o) { ... } }   // только БД

class OrderNotificationService { void sendConfirmation(Order o) { ... } } // только электронная почта

O — Принцип открытости/закрытости

Формулировка Бертрана Мейера (1988), переосмысленная Мартином: «Программные сущности должны быть открыты для расширения, но закрыты для модификации». Класс закрыт для модификации, когда его проверенный, задеплоенный код не нужно менять для добавления нового поведения. Он открыт для расширения, когда новое поведение добавляется написанием нового кода — нового подкласса, новой реализации стратегии, нового декоратора — без прикосновения к существующему классу. Самый распространённый механизм: зависеть от абстракций (интерфейсов) и внедрять конкретные реализации.

Нажмите на подсвеченные строки, чтобы увидеть нарушение и исправление OCP

java

// ── НАРУШЕНИЕ: каждый новый способ оплаты требует модификации ───

class PaymentProcessor {

  void process(Payment p) {

▼

    if (p.type() == CREDIT_CARD) chargeCard(p);

    else if (p.type() == PAYPAL)  chargePayPal(p);

    else if (p.type() == CRYPTO)  chargeCrypto(p);  // добавлено позже — изменён существующий класс

// ── ИСПРАВЛЕНИЕ: закрыт для модификации, открыт для расширения ──

interface PaymentGateway { void charge(Payment p); }

▼

class CreditCardGateway  implements PaymentGateway { ... }

class PayPalGateway       implements PaymentGateway { ... }

class CryptoGateway       implements PaymentGateway { ... }  // новый метод = только новый класс

class PaymentProcessor {

  private final Map<PaymentType, PaymentGateway> gateways;

  void process(Payment p) {

    gateways.get(p.type()).charge(p);  // никогда не изменяется

L — Принцип подстановки Барбары Лисков

Формулировка Барбары Лисков (1987): «Если S является подтипом T, то объекты типа T можно заменять объектами типа S, не нарушая желательных свойств программы». Простыми словами: подкласс должен соблюдать контракт суперкласса — не только сигнатуры методов, но и поведенческие ожидания (предусловия, постусловия, инварианты). Классическое нарушение LSP — проблема Квадрата-Прямоугольника: Square расширяет Rectangle, но переопределение setWidth с одновременным изменением height нарушает контракт прямоугольника о независимости ширины и высоты.

Нажмите на подсвеченные строки, чтобы понять нарушение LSP и правильный дизайн

java

// ── НАРУШЕНИЕ: Квадратный переход поведенческого контракта Прямоугольник ─

class Rectangle {

  protected int width, height;

  void setWidth(int w)  { this.width = w; }

  void setHeight(int h) { this.height = h; }

  int area() { return width * height; }

class Square extends Rectangle {

▼

  @Override void setWidth(int w)  { width = height = w; }  // Договор контракта Прямоугольник

  @Override void setHeight(int h) { width = height = h; }  // Договор контракта Прямоугольник

// Клиентский код ломается при подстановке «Квадрат» вместо «Прямоугольник»:

// rect.setWidth(5); rect.setHeight(4); утверждать rect.area() == 20; // ПРОВАЛ для Square

// ── ИСПРАВЛЕНИЕ: моделируем реальное отношение — без наследования ─

interface Shape { int area(); }

▼

record Rectangle(int width, int height) implements Shape {

  public int area() { return width * height; }

record Square(int side) implements Shape {

  public int area() { return side * side; }

I — Принцип разделения интерфейсов

Формулировка Мартина: «Клиенты не должны зависеть от интерфейсов, которые они не используют». Толстые интерфейсы — с множеством несвязанных методов — вынуждают реализаторов создавать заглушки для методов, которые им не нужны, а клиентов — импортировать тип, несущий возможности, которые им не нужны. ISP говорит: предпочитайте множество маленьких клиентских интерфейсов одному большому. Проектное давление ISP естественно порождает Ролевые Интерфейсы — интерфейсы, описывающие роль объекта (Printable, Saveable, Auditable), а не полный перечень всего, что объект умеет.

Нажмите на подсвеченные строки, чтобы понять нарушение ISP и ролевые интерфейсы

java

// ── НАРУШЕНИЕ: толстый интерфейс принуждает к ненужным заглушкам ─

interface Worker {

▼

  void work();

  void takeBreak();      // нерелевантно для робота

  void receivePaycheck(); // нерелевантно для робота

class Robot implements Worker {

  public void work() { ... }

  public void takeBreak() { /* Robot не отдыхает — принудительная заглушка */ }

  public void receivePaycheck() { /* Robot не получает зарплату — заглушка */ }

// ── ИСПРАВЛЕНИЕ: маленькие ролевые интерфейсы ───────────────────

interface Workable  { void work(); }

▼

interface Breakable { void takeBreak(); }

interface Payable   { void receivePaycheck(); }

class Robot      implements Workable { ... }                        // только нужное

class HumanWorker implements Workable, Breakable, Payable { ... }   // полный набор

// Планировщику нужен только в Работоспособных — не знает о перерывах и потрясающих:

class ProductionScheduler { void schedule(List<Workable> workers) { ... } }

D — Принцип инверсии зависимостей

Формулировка Мартина: «(A) Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракций. (B) Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций». DIP — это принцип, лежащий в основе Луковой архитектуры, Гексагональной архитектуры и Чистой архитектуры. Он же делает внедрение зависимостей осмысленным: DI — это механизм; DIP — это причина.

Нажмите на подсвеченные строки, чтобы проследить инверсию зависимостей от нарушения к исправлению

java

// ── НАРУШЕНИЕ: модуль верхнего уровня зависит от детали ─────────

class OrderService {

▼

  private final MySqlOrderRepository repo = new MySqlOrderRepository();

  void confirm(Long id) {

    Order order = repo.findById(id);

    order.confirm();

    repo.save(order);

// ── ИСПРАВЛЕНИЕ: оба зависят от абстракции ───────────────────────

interface OrderRepository { Order findById(Long id); void save(Order o); }

▼

class OrderService {

  private final OrderRepository repo;  // зависит от абстракции

  OrderService(OrderRepository repo) { this.repo = repo; }  // DI через конструктор

  void confirm(Long id) { ... }  // логика не изменилась

// Низкоуровневая деталь зависит от абстракции (не наоборот):

class MySqlOrderRepository implements OrderRepository { ... }    // продакшен

class InMemoryOrderRepository implements OrderRepository { ... } // тесты

SOLID на практике: полная картина

Быстрый справочник: какую проблему решает каждый принцип и какой механизм предписывает

Принцип	Устраняемый симптом	Механизм	Архитектурный эффект
SRP	Классы меняются по нескольким несвязанным причинам; конфликты слияния; разрозненные тесты	Разделить по актору/причине изменения	Двигает к модульной декомпозиции; независимый деплой
OCP	Добавление фич требует модификации проверенного кода; растущие цепочки if/else	Зависеть от абстракций; расширять добавлением новых реализаций	Плагинные архитектуры, паттерн Strategy, точки расширения
LSP	Подклассы, ломающие вызывающий код; UnsupportedOperationException в переопределениях	Соблюдать поведенческий контракт, не только сигнатуры	Гарантирует подстановляемость в полиморфных иерархиях; композиция вместо наследования
ISP	Реализация нерелевантных методов; толстые интерфейсы, часто меняющиеся	Маленькие ролевые интерфейсы для каждого клиента	Снижает связанность между модулями
DIP	Высокоуровневый код зависит от БД/фреймворка; не тестируется без инфраструктуры	Абстракции в пакете высокого уровня; детали внедряются	Основа Луковой/Гексагональной/Чистой архитектуры; тест-дублёры

Типичные ошибки при применении SOLID

Главный вывод: принципы SOLID адресуют пять конкретных сбоев объектно-ориентированного проектирования. SRP предотвращает связанность из-за нескольких акторов. OCP предотвращает модификацию проверенного кода. LSP предотвращает нарушения поведенческого контракта в иерархиях. ISP предотвращает связанность через толстые интерфейсы. DIP предотвращает зависимость высокоуровневого кода от деталей. Применяйте их там, где присутствует симптом — не как универсальный шаблон для каждого класса.

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