Что такое принцип Interface Segregation?

Глубокое погружение (Under the Hood)

Принцип разделения интерфейсов (ISP) гласит: “Клиенты не должны зависеть от методов, которые они не используют.

Клиент — класс, который зависит от интерфейса (вызывает его методы или реализует его). Если интерфейс заставляет класс реализовывать методы, которые ему не нужны — ISP нарушен.”

На уровне байт-кода и JVM большой интерфейс (Fat Interface) создает лишние зависимости в Constant Pool каждого класса-реализатора. Constant Pool — таблица ссылок в .class файле. Каждый метод интерфейса добавляет запись. VTable — таблица виртуальных методов. Больше методов = больше таблица = чуть больше памяти и медленнее вызов. Но главная проблема — архитектурная: “загрязнение” кода методами-заглушками.

Senior-инсайт: Role Interfaces vs Header Interfaces

1. Header Interfaces (Антипаттерн)

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

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

2. Role Interfaces (Senior Approach)

Интерфейс должен описывать роль объекта в конкретном взаимодействии, а не все его возможности.

Один класс может реализовывать 10 маленьких интерфейсов-ролей (Serializable, Cloneable, Printable).
Клиент (напр. принтер) требует только Printable, и ему всё равно, умеет ли объект сохраняться в БД.

Признаки нарушения ISP

UnsupportedOperationException: Самый яркий признак. Вы реализовали метод только потому, что интерфейс заставил, но логики для него нет.
Пустые методы: Аналогично, метод просто ничего не делает.
Жирные контракты: Когда для тестирования метода вам нужно мокать 20 функций в интерфейсе, хотя метод использует только одну.

Решение через паттерн Adapter

Иногда вы не можете изменить “жирный” интерфейс сторонней библиотеки. В этом случае используйте Adapter:

// Сторонний жирный интерфейс
public interface ThirdPartyCloud {
    void upload();
    void delete();
    void list();
    void billing(); // Нам это не нужно
}

// Наш узкий интерфейс
public interface SimpleUploader {
    void upload();
}

// Адаптер соблюдает ISP для нашего приложения
public class CloudAdapter implements SimpleUploader {
    private final ThirdPartyCloud cloud;
    public void upload() { cloud.upload(); }
}

Производительность и Highload

Binary Compatibility: ISP повышает бинарную совместимость. Если вы добавите метод в узкий интерфейс Payment, это затронет только те сервисы, которые реально работают с платежами, а не весь проект.
Cache Locality: Меньшее количество методов в интерфейсе (и, соответственно, в VTable объектов) теоретически может чуть лучше укладываться в кэш инструкций процессора, но на практике это микрооптимизация.

Пограничные случаи (Edge Cases)

Default Methods (Java 8+): Позволяют добавлять методы в интерфейсы без поломки реализаций. Однако это не спасает от нарушения ISP. Интерфейс всё равно остается “жирным”, просто теперь он засоряет пространство имен клиента методами по умолчанию.
Single Method Interfaces: Одно-методные интерфейсы — хороший ориентир, но не догма. Интерфейс с 2-3 связанными методами (например, open()/close()/isOpen()) тоже может быть правильным.

Когда НЕ стоит строго следовать ISP

Интерфейс с 1-2 методами — нет смысла дробить дальше
Все реализации используют все методы — разделение не принесёт пользы
Внутренний интерфейс пакета — не виден снаружи, влияние минимально

Резюме для Senior

Интерфейсы принадлежат клиентам, а не реализациям.
Предпочитайте много маленьких интерфейсов одному большому.
Используйте Default Methods с осторожностью.
Помните: ISP уменьшает связность (Coupling) и упрощает тестирование через уменьшение количества моков.

🎯 Шпаргалка для интервью

Обязательно знать:

ISP: клиенты не должны зависеть от методов, которые они не используют
Fat Interface заставляет классы реализовывать ненужные методы → UnsupportedOperationException и заглушки
Role Interfaces > Header Interfaces: интерфейс описывает роль, а не все возможности класса
Интерфейсы принадлежат клиентам, а не реализациям
Adapter паттерн помогает соблюсти ISP для сторонних библиотек
Default Methods (Java 8+) не спасают от нарушения ISP — просто засоряют пространство имён

Частые уточняющие вопросы:

Header Interface vs Role Interface? — Header копирует все методы класса (антипаттерн), Role описывает конкретную роль (Printable, Serializable)
Как ISP упрощает тестирование? — Меньше моков: тестируемый класс зависит только от нужных методов
Нужно ли дробить интерфейс с 1-2 методами? — Нет, дальнейшее дробление не принесёт пользы
Как ISP связан с DIP? — Узкие интерфейсы — более стабильные абстракции, от которых зависят модули

Красные флаги (НЕ говорить):

“Для каждого класса нужен свой интерфейс” (это Header Interface — антипаттерн)
“Default methods решают проблему ISP” (нет, интерфейс всё равно остаётся жирным)
“Интерфейс на 20 методов — это нормально” (зависит от того, сколько методов использует клиент)

Связанные темы:

[[8. Что такое принцип Dependency Inversion]]
[[3. Что такое принцип Open_Closed]]
[[5. Что такое принцип Liskov Substitution]]
[[15. Как SOLID помогает в тестировании кода]]