SOLID на котиках: коротко и по делу

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

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

Что такое SOLID и зачем это нужно?

SOLID — это пять принципов проектирования, которые помогают писать читаемый, сопровождаемый и расширяемый код.

• S (Single Responsibility): один класс — одна ответственность.

• O (Open/Closed): открыт для расширения, закрыт для изменения.

• L (Liskov Substitution): дочерние классы заменяют родительские без сюрпризов.

• I (Interface Segregation): узкие интерфейсы лучше широких.

• D (Dependency Inversion): зависимость от абстракций, а не реализаций.

Зачем это нужно?

• Изменение одной части приложения ломает всё (нарушение S).

• Добавление новой фичи требует переписывать старый код (нарушение O).

• Наследники ведут себя непредсказуемо (нарушение L).

• Перегруженные интерфейсы заставляют писать лишний код (нарушение I).

• Зависимость от конкретных реализаций делает код негибким (нарушение D).

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

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

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

Каждый класс должен отвечать за одну-единственную задачу. Т.е он должен быть о чём-то одном.

Вы наверняка видели такой код:

public class Cat {     private String name;      public Cat(String name) {         this.name = name;     }      public void eat() {         System.out.println(name + " ест.");     }      public void sleep() {         System.out.println(name + " спит.");     }      public void cleanLitterBox() {         System.out.println("Убираем лоток для " + name + ".");     } }

На первый взгляд — всё нормально. Но проблема станет явной, как только понадобится переиспользовать логику cleanLitterBox в классе, не связанном с котами. Например, вы захотите сделать уборку универсальной для всех домашних животных. Тут начнётся переписывание кода.

Разделим всё на отдельные классы:

public class Cat {     private final String name;      public Cat(String name) {         this.name = name;     }      public void eat() {         System.out.println(name + " ест.");     }      public void sleep() {         System.out.println(name + " спит.");     } }  public class LitterBoxService {     public void cleanLitterBox(String animalName) {         System.out.println("Убираем лоток для " + animalName + ".");     } }

Теперь Cat занимается только своим поведением, а уборка делегирована сервису. Хотите добавить собачку? Это получится легко.

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

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

Допустим, нужно добавить новых котов и пишем код вот так:

public class CatService {     public void makeSound(String catType) {         if (catType.equals("домашний")) {             System.out.println("Мяу!");         } else if (catType.equals("дикий")) {             System.out.println("Ррр!");         } else {             throw new IllegalArgumentException("Неизвестный тип кота.");         }     } }

Каждый новый тип кота — новая ветка в if-else. Этот код плохо тестируется, и его сложно поддерживать.

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

public interface Cat {     void makeSound(); }  public class DomesticCat implements Cat {     @Override     public void makeSound() {         System.out.println("Мяу!");     } }  public class WildCat implements Cat {     @Override     public void makeSound() {         System.out.println("Ррр!");     } }

А теперь сервис:

public class CatService {     public void playWithCat(Cat cat) {         cat.makeSound();     } }

При добавлении нового кота мы просто пишем новый класс. Сервис остаётся неизменным. Это и есть принцип открытости/закрытости.

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

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

Пример:

public class Cat {     public void eat() {         System.out.println("Кот ест.");     } }  public class ToyCat extends Cat {     @Override     public void eat() {         throw new UnsupportedOperationException("Игрушечный кот не ест.");     } }

Если метод работает с Cat, то передача ToyCat вызовет ошибку.

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

public interface Cat {     void makeSound(); }  public class RealCat implements Cat {     @Override     public void makeSound() {         System.out.println("Мяу!");     } }  public class ToyCat implements Cat {     @Override     public void makeSound() {         System.out.println("Пи-пи!");     } }

Теперь ToyCat никогда не вызовет UnsupportedOperationException.

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

Большие интерфейсы — зло. Лучше несколько маленьких, чем один огромный.

Раздутый интерфейс:

public interface Cat {     void eat();     void sleep();     void climbTree(); }

Не все коты лазают по деревьям. Если HouseCat имплементирует этот интерфейс, ему придётся писать пустую реализацию climbTree.

Разделим интерфейсы по ролям:

public interface BasicCat {     void eat();     void sleep(); }  public interface TreeClimbingCat {     void climbTree(); }

Теперь классы реализуют только то, что им нужно:

public class HouseCat implements BasicCat {     @Override     public void eat() {         System.out.println("Мяу, я ем.");     }      @Override     public void sleep() {         System.out.println("Я дремлю.");     } }  public class ForestCat implements BasicCat, TreeClimbingCat {     @Override     public void eat() {         System.out.println("Я ем мышей.");     }      @Override     public void sleep() {         System.out.println("Дремлю на дереве.");     }      @Override     public void climbTree() {         System.out.println("Лазаю по деревьям.");     } }

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

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

Прямые зависимости:

public class Cat {     private final DryFood food = new DryFood();      public void eat() {         food.consume();     } }  public class DryFood {     public void consume() {         System.out.println("Кот ест сухой корм.");     } }

Теперь Cat жёстко завязан на DryFood.

Внедрение зависимостей:

public class Cat {     private final Food food;      public Cat(Food food) {         this.food = food;     }      public void eat() {         food.consume();     } }  public interface Food {     void consume(); }  public class DryFood implements Food {     @Override     public void consume() {         System.out.println("Кот ест сухой корм.");     } }  public class WetFood implements Food {     @Override     public void consume() {         System.out.println("Кот ест влажный корм.");     } }

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

---

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

Код, построенный на принципах SOLID, переживёт не только первый релиз, но и бесконечные «давайте добавим ещё вот это» от бизнеса. Он станет тем проектом, который другие разработчики будут вспоминать с теплотой, а не с дрожью.

Так что, следующий раз, когда будете писать класс или проектировать систему, подумайте о SOLID. Не потому, что это красиво звучит, а потому что это спасёт вас от десятков бессонных ночей.

Статья подготовлена в рамках специализации «Java-разработчик». Прочитать полную программу и посмотреть записи открытых уроков можно на странице курса.