Что такое принцип разделения интерфейса?

Принцип разделения интерфейса (Interface Segregation Principle)

Это один из пяти SOLID принципов, сформулированный Робертом Мартином. Суть: клиенты не должны зависеть от интерфейсов, которые они не используют. Лучше иметь много специализированных интерфейсов, чем один монолитный.

Проблема: Толстые интерфейсы

Антипаттерн — монолитный интерфейс:

// ❌ Плохо — один большой интерфейс
public interface Worker {
    void work();           // Все работают
    void eat();            // Не все едят во время работы
    void sleep();          // Не все спят на работе
    void getReport();      // Не все создают отчёты
    void manageTeam();     // Не все управляют командой
}

// Робот должен реализовать ВСЕ методы, хотя не все релевантны
public class Robot implements Worker {
    @Override
    public void work() { /* код */ }
    
    @Override
    public void eat() { /* выбросить исключение? */ }
    
    @Override
    public void sleep() { /* выбросить исключение? */ }
    
    @Override
    public void getReport() { /* код */ }
    
    @Override
    public void manageTeam() { /* выбросить исключение? */ }
}

Проблемы:

• Класс Robot вынужден реализовать методы, которые бессмысленны (eat, sleep)
• Нарушается Contract интерфейса
• Сложнее тестировать и поддерживать
• Слабая когезия между методами

Решение: Разделение интерфейсов

✅ Правильный подход — специализированные интерфейсы:

// Маленькие, сфокусированные интерфейсы
public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

public interface Sleepable {
    void sleep();
}

public interface Reportable {
    void getReport();
}

public interface Manageable {
    void manageTeam();
}

// Теперь каждый класс реализует только нужные интерфейсы
public class Human implements Workable, Eatable, Sleepable, Reportable, Manageable {
    @Override
    public void work() { System.out.println("Человек работает"); }
    
    @Override
    public void eat() { System.out.println("Человек ест"); }
    
    @Override
    public void sleep() { System.out.println("Человек спит"); }
    
    @Override
    public void getReport() { System.out.println("Человек делает отчёт"); }
    
    @Override
    public void manageTeam() { System.out.println("Человек управляет командой"); }
}

public class Robot implements Workable, Reportable {
    @Override
    public void work() { System.out.println("Робот работает"); }
    
    @Override
    public void getReport() { System.out.println("Робот готовит отчёт"); }
    // Никаких eat() и sleep() — как и должно быть!
}

public class Dog implements Workable, Eatable, Sleepable {
    @Override
    public void work() { System.out.println("Собака работает (охраняет)"); }
    
    @Override
    public void eat() { System.out.println("Собака ест"); }
    
    @Override
    public void sleep() { System.out.println("Собака спит"); }
    // Никаких отчётов и управления командой
}

Реальный пример из enterprise разработки

Ситуация: система платежей

// ❌ Плохо — один большой интерфейс
public interface PaymentProcessor {
    boolean processPayment(double amount);
    boolean refund(double amount);
    String getTransactionHistory();
    void validateCard(String cardNumber);
    void fraud Detection();
    void settlement();
    void reconciliation();
}

// Мобильный платёж не нужны все эти методы
public class MobilePaymentGateway implements PaymentProcessor {
    // вынужден реализовать всё...
}

✅ Правильно — разделённые интерфейсы:

public interface PaymentGateway {
    boolean processPayment(double amount);
    boolean refund(double amount);
}

public interface CardValidator {
    void validateCard(String cardNumber);
}

public interface FraudDetector {
    void detectFraud();
}

public interface TransactionReporter {
    String getTransactionHistory();
}

public interface SettlementService {
    void settlement();
    void reconciliation();
}

// Мобильный платёж
public class MobilePaymentGateway implements PaymentGateway, FraudDetector {
    @Override
    public boolean processPayment(double amount) { /* ... */ }
    
    @Override
    public boolean refund(double amount) { /* ... */ }
    
    @Override
    public void detectFraud() { /* ... */ }
}

// Кредитная карта
public class CardPaymentGateway implements PaymentGateway, CardValidator, FraudDetector, SettlementService {
    // полная реализация
}

Когда применять разделение

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

• ✋ Класс реализует методы, которые выбрасывают UnsupportedOperationException
• ✋ Класс не использует большинство методов интерфейса
• ✋ Клиенты кода вынуждены зависеть от методов, которые не используют
• ✋ Интерфейс имеет методы для разных целей

Баланс между разделением и простотой

// Не переусложнять!
// ✅ Хорошо — 2-4 метода в интерфейсе
public interface Repository<T> {
    T findById(Long id);
    List<T> findAll();
    void save(T entity);
    void delete(T entity);
}

// ❌ Плохо — по интерфейсу на каждый метод
public interface Findable<T> {
    T findById(Long id);
}

public interface Saveable<T> {
    void save(T entity);
}

public interface Deletable<T> {
    void delete(T entity);
}

Связь с другими SOLID принципами

ISP работает рука об руку с Dependency Inversion:

// ✅ Клиент зависит от маленького интерфейса
public class OrderService {
    private PaymentGateway gateway; // Зависит только от необходимого
    
    public OrderService(PaymentGateway gateway) {
        this.gateway = gateway;
    }
    
    public void checkout(double amount) {
        gateway.processPayment(amount);
        // Не нужно знать про settlement, reconciliation и т.д.
    }
}

Итог

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

• Более гибким — легче комбинировать разные реализации
• Более тестируемым — можно мокировать только нужный функционал
• Более понятным — явное указание, что класс должен делать
• Менее хрупким — изменения в одной части не ломают другие