Для чего методы разделили на группы

# Для чего методы разделили на группы?

Контекст: Разделение методов в Java Collection API

В Java Collection API (и вообще в Java) методы разделены на группы в разные интерфейсы и классы по логическому смыслу. Это следует из принципа Interface Segregation Principle (ISP) из SOLID.

Основные причины разделения методов

1. Разделение ответственности

// Плохо - все методы в одном интерфейсе
interface Collection {
    void add(E e);           // Добавление
    void remove(E e);        // Удаление
    boolean contains(E e);   // Поиск
    Stream<E> stream();      // Работа со stream
    Iterator<E> iterator();  // Итерация
    void sort(Comparator c); // Сортировка
    void parallelStream();   // Параллельная обработка
}

// Хорошо - разделено по смыслу
interface Collection<E> {
    void add(E e);
    void remove(E e);
    boolean contains(E e);
}

interface Iterable<E> {
    Iterator<E> iterator();
}

interface Stream<T> {
    Stream<T> map(Function<T, R> mapper);
    void forEach(Consumer<T> action);
}

2. Гибкость реализации

Разные коллекции могут реализовать разные наборы методов:

// List поддерживает индексный доступ
public interface List<E> extends Collection<E> {
    E get(int index);           // Только для List
    void add(int index, E e);   // Только для List
    int indexOf(Object o);      // Только для List
}

// Set не поддерживает индексный доступ
public interface Set<E> extends Collection<E> {
    // Нет методов get(), add(int, E)
    // Но есть методы для работы с множеством
}

// Map - совсем другая иерархия
public interface Map<K, V> {
    V put(K key, V value);
    V get(K key);
    // Совсем не наследует Collection
}

3. Примеры разделения в Java

// Иерархия Collection API:
// Iterable
//   └─ Collection
//       ├─ List
//       ├─ Set
//       └─ Queue
// Map (отдельно)

// Каждый уровень добавляет новые методы:

interface Iterable<T> {
    Iterator<T> iterator();      // Только итерация
}

interface Collection<E> extends Iterable<E> {
    boolean add(E e);
    boolean remove(Object o);
    boolean contains(Object o);
    int size();
    void clear();
    // и другие...
}

interface List<E> extends Collection<E> {
    E get(int index);            // Индексный доступ
    E set(int index, E element);
    void add(int index, E element);
    E remove(int index);
    int indexOf(Object o);
}

4. Разделение по функциональности

// В Java Streams API:
interface Stream<T> {
    // Промежуточные операции (возвращают Stream)
    Stream<T> filter(Predicate<T> predicate);
    <R> Stream<R> map(Function<T, R> mapper);
    Stream<T> distinct();
    
    // Терминальные операции (возвращают результат)
    void forEach(Consumer<T> action);
    List<T> collect(Collector<T, ?, List<T>> collector);
    Optional<T> findFirst();
}

5. Правило Interface Segregation Principle (ISP)

// Плохо - клиента заставляют реализовать ненужные методы
interface Worker {
    void work();
    void eat();  // Не все workers едят (например, Robot)
}

class Robot implements Worker {
    public void work() { /* ... */ }
    public void eat() { /* Вынужден реализовать */ }
}

// Хорошо - разделено по смыслу
interface Worker {
    void work();
}

interface Eater {
    void eat();
}

class Human implements Worker, Eater {
    public void work() { /* ... */ }
    public void eat() { /* ... */ }
}

class Robot implements Worker {
    public void work() { /* ... */ }
    // Не нужно реализовать eat()
}

Практические примеры из стандартной библиотеки

Пример 1: Collections Framework

// Пользователь может работать с базовым интерфейсом
public void process(Collection<String> items) {
    items.add("item");
    items.remove("item");
    for (String item : items) {
        System.out.println(item);
    }
}

// И передать любую реализацию
process(new ArrayList<>());    // List
process(new HashSet<>());      // Set
process(new LinkedList<>());   // Queue

// Или работать с конкретным типом
public void processWithIndex(List<String> items) {
    for (int i = 0; i < items.size(); i++) {
        System.out.println(items.get(i));  // Индексный доступ
    }
}

processWithIndex(new ArrayList<>());   // OK
processWithIndex(new HashSet<>());     // Compilation Error! Set не List

Пример 2: Comparable vs Comparator

// Разделены потому что:
// 1. Объект может быть сравним с собой (Comparable)
// 2. Или сравним по внешнему критерию (Comparator)

interface Comparable<T> {
    int compareTo(T o);  // Сравнение с другим объектом
}

interface Comparator<T> {
    int compare(T o1, T o2);  // Внешнее сравнение
}

// Использование
class User implements Comparable<User> {
    private String name;
    
    public int compareTo(User other) {
        return this.name.compareTo(other.name);
    }
}

// А для сортировки по другим критериям - используем Comparator
Comparator<User> byAge = (u1, u2) -> Integer.compare(u1.age, u2.age);
List<User> users = new ArrayList<>();
users.sort(byAge);  // Сортировка по возрасту

Преимущества разделения методов

// 1. Минимальная ответственность класса
class ArrayList<E> implements List<E>, RandomAccess, Cloneable {
    // Реализует то, что ему нужно
}

// 2. Гибкое использование
public List<T> readOnly(List<T> list) {
    return Collections.unmodifiableList(list);  // Читаем Collection
}

public void modify(List<T> list) {
    list.add(new T());  // Модифицируем List
}

// 3. Расширяемость
// Можно добавить новые методы без изменения существующих
interface Collection<E> {  // Базовые методы
    void add(E e);
    void remove(E e);
}

interface List<E> extends Collection<E> {  // Добавляем индексный доступ
    E get(int index);
}

interface Sortable<E> extends List<E> {  // Добавляем сортировку
    void sort(Comparator<E> cmp);
}

Итог

Методы разделены на группы для:

1. Соблюдения SOLID принципов (ISP)
2. Гибкости — можно передать объект, реализующий только нужный интерфейс
3. Ясности — каждый интерфейс отвечает за одну ответственность
4. Расширяемости — легко добавлять новые методы
5. Минимизации ответственности — класс реализует только то, что ему нужно
6. Контрактов — ясно, что поддерживает объект

Это один из ключевых принципов хорошего дизайна в Java и других ОО языках.