📐 Раздел 18 · Вопрос #12

Что такое делегирование в ООП

При этом для внешнего клиента объект-делегатор продолжает выступать ответственным исполнителем.

📐 ООП и SOLID 📄 Исходный Markdown

🟢 Junior Level

Делегирование (Delegation) — это подход в объектно-ориентированном программировании, при котором объект, получив запрос на выполнение действия, не реализует его самостоятельно, а перенаправляет (делегирует) задачу другому объекту-помощнику.

При этом для внешнего клиента объект-делегатор продолжает выступать ответственным исполнителем.

Житейская аналогия

Руководитель проекта и программист:

  • Клиент обращается к руководителю проекта: «Добавьте в мобильное приложение оплату через СБП».
  • Руководитель не пишет код сам: он перенаправляет (делегирует) техническую задачу разработчику.
  • Однако для клиента интерфейсом остается руководитель: он принимает задачу и возвращает готовый результат.

Простой пример делегирования в Java

// 1. Делегат (реальный исполнитель)
public class SmsSender {
    public void send(String phone, String text) {
        System.out.println("Отправка SMS на " + phone + ": " + text);
    }
}

// 2. Делегатор (координатор)
public class NotificationManager {
    // Внутренний объект-делегат
    private final SmsSender smsSender;

    public NotificationManager(SmsSender smsSender) {
        this.smsSender = smsSender;
    }

    public void notifyCustomer(String phone, String message) {
        // Дополнительная валидация или логирование
        System.out.println("Логируем отправку сообщения...");

        // ДЕЛЕГИРОВАНИЕ выполнения
        smsSender.send(phone, message);
    }
}

Зачем нужно делегирование:

  • Альтернатива наследованию: вместо создания сложной и жесткой иерархии классов мы комбинируем готовые объекты.
  • Гибкость: объект-делегат можно легко заменить в конструкторе или через сеттер в рантайме.

🟡 Middle Level

Тонкое различие: True Delegation против Forwarding (Переадресации)

В академической теории ООП (Генри Либерман, 1986; GoF) принято строго различать два термина, которые в повседневной Java-разработке часто объединяют словом «делегирование»:

Критерий Forwarding (Переадресация) True Delegation (Истинное делегирование)
Передача контекста (this) Нет. Объект A просто вызывает b.operation(). Внутри метода operation() ссылка this указывает на объект B. Да. Объект A передает ссылку на себя: b.operation(this). Внутри B контекстом исполнения остается A.
Реализация в Java 99% стандартного Java-кода (композиция, паттерн Wrapper). Паттерны Visitor, State, Strategy, где стратегии явно передается контекст владельца.
Проблема this (The Self-Problem) Отсутствует. Методы B изолированы от A. Присутствует: если B вызывает свои собственные переопределяемые методы, возникает путаница с полиморфизмом.

Делегирование в стандартной библиотеке JDK

Делегирование лежит в основе множества классов Java Core:

  1. java.util.Collections.synchronizedList(list): Класс SynchronizedList реализует интерфейс List, хранит внутри приватный final List<E> list и оборачивает каждый вызов в блок синхронизации: 
    public int size() {
    synchronized (mutex) { return list.size(); } // Делегирование с синхронизацией
}
  2. java.io.InputStream и декораторы: BufferedInputStream и GZIPInputStream наследуют FilterInputStream, который полностью делегирует чтение байт внутреннему потоку in.read(), добавляя кэширование или распаковку.

Делегирование vs Dynamic Proxy (JDK / ByteBuddy)

Характеристика Явное делегирование (Compile-time) Динамический прокси (Runtime Proxy)
Реализация Пишется вручную (или генерируется Lombok @Delegate). Генерируется на лету (java.lang.reflect.Proxy, CGLIB, ByteBuddy).
Типобезопасность Строгая проверка компилятором Java. Ошибки конфигурации часто выявляются только в Runtime.
Производительность Скорость прямого вызова (0.3–1 ns при инлайнинге JIT). Накладные расходы рефлексии и интерцепторов (30–150 ns).
Назначение Архитектурная декомпозиция бизнес-логики. Сквозная функциональность (Spring AOP, @Transactional, Security).

🔴 Senior Level

Проблема селф-диспетчеризации (The Self-Problem Либермана)

В языках с нативной поддержкой делегирования (Self, JavaScript прототипы) вызов метода делегата сохраняет исходный контекст this. В Java симуляция истинного делегирования наталкивается на фундаментальное ограничение:

public class Window {
    private final Rectangle bounds;

    public Window(Rectangle bounds) {
        this.bounds = bounds;
    }

    public int getArea() {
        return bounds.getArea(this); // Передаем себя как контекст
    }

    public int getBorderWidth() { return 2; }
}

public class Rectangle {
    private int w, h;
    public int getArea(Window context) {
        // Делегат вынужден опрашивать делегатора о его свойствах
        return (w + context.getBorderWidth()) * (h + context.getBorderWidth());
    }
}

Если забыть передать this, внутренняя логика делегата будет оперировать собственным состоянием, теряя полиморфные переопределения делегатора.

Анализ JIT-компиляции HotSpot (C2) и Devirtualization

Скептики часто заявляют: «Делегирование создает лишний уровень косвенности (Indirection) и замедляет выполнение из-за дополнительных вызовов функций».

На уровне ассемблерного кода HotSpot JVM это не так:

  1. Monomorphic Call Site Inlining: Если поле-делегат объявлено как private final Processor delegate, компилятор C2 выполняет Class Hierarchy Analysis (CHA). Обнаружив ровно одну активную реализацию метода, JIT выполняет Method Inlining: машинный код метода делегата встраивается прямо в точку вызова делегатора. Накладные расходы вызова превращаются в ноль наносекунд!
  2. Bimorphic Inline Caching: Если в рантайме чередуются 2 типа делегата (например, FastSmsSender и BackupSmsSender), JIT строит быструю conditional-проверку (cmp klass; jne fallback) и инлайнит тела обоих методов.
  3. Megamorphic Fallback: Если типов делегата $\ge 3$, JIT переходит к поиску по таблице интерфейсов itable. В этом случае косвенный переход стоит ~10–15 тактов CPU.

Делегирование в современных языках: Kotlin vs Java + Lombok

  • В Kotlin делегирование встроено в синтаксис языка через оператор by: 
    class FastList<T>(private val inner: List<T>) : List<T> by inner
// Компилятор автоматически генерирует все 25 методов-делегатов интерфейса List!
  • В Java для устранения многословного boilerplate-кода применяют библиотеку Lombok: 
    public class CustomCollection<E> implements Collection<E> {
    @Delegate
    private final Collection<E> internalStorage = new ArrayList<>();
    // Lombok на этапе компиляции генерирует методы-делегаты
}

4 Tricky Questions

1. Что произойдет при возникновении циклического делегирования (Circular Delegation) и как его предотвратить?

Ответ: Если объект A в процессе обработки делегирует вызов объекту B, а B в своей логике снова вызывает метод объекта A, виртуальная машина входит в бесконечную рекурсию. Это приводит к переполнению стека вызовов и фатальной ошибке java.lang.StackOverflowError. Предотвращение:

  1. Архитектурное правило однонаправленности: зависимости должны образовывать направленный ациклический граф (DAG).
  2. Автоматический контроль в CI: тесты ArchUnit (slices().matching("..").should().notCycleDependency()), запрещающие циклические связи между пакетами и классами.

2. Является ли паттерн Decorator разновидностью делегирования?

Ответ: Да. Декоратор (Decorator) — это специализированная форма делегирования, объединенная с общим интерфейсом:

  1. Декоратор реализует тот же самый интерфейс, что и оборачиваемый объект (Decorator implements Component).
  2. Декоратор хранит ссылку на экземпляр Component в поле.
  3. Все стандартные методы интерфейса он делегирует этому экземпляру, но до или после делегирования добавляет собственное прозрачное поведение (кэширование, аудит, шифрование).

3. Как делегирование влияет на потокобезопасность (Thread-Safety), если делегатор и делегат имеют собственное состояние?

Ответ: Если делегатор синхронизирует вызовы на своем мониторе (synchronized(this)), это не защищает внутреннее состояние делегата, если на того есть прямая ссылка у других потоков. Для обеспечения потокобезопасности:

  • Делегат должен быть полностью инкапсулирован внутри делегатора (никаких геттеров наружу, защитное копирование в конструкторе).
  • Либо сам делегат должен быть потокобезопасным (например, AtomicInteger, ConcurrentHashMap).
  • Если делегат stateless (не имеет изменяемых полей), делегирование потокобезопасно по умолчанию.

4. В чем опасность использования аннотации Lombok @Delegate в enterprise-проектах?

Ответ: Аннотация @Delegate слепо делегирует все публичные методы типа поля. Это порождает две серьезные проблемы:

  1. Нарушение Interface Segregation Principle (ISP) и утечка API: класс непреднамеренно выставляет наружу десятки ненужных или опасных методов делегата (например, методы мутации внутренней коллекции).
  2. Хрупкость сборки: при обновлении сторонней библиотеки делегата, в его интерфейсе могут появиться новые методы, сигнатуры которых конфликтуют с собственными методами класса-делегатора, что приведет к ошибкам компиляции. Безопаснее использовать ручную генерацию методов-делегатов средствами IDE (IntelliJ IDEA: Generate -> Delegate Methods) с выбором только необходимых методов.

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

Главные тезисы (30 секунд на ответ):

  • Суть: Объект перенаправляет выполнение задачи другому объекту-помощнику, оставаясь точкой входа для клиента.
  • Duality: Основа композиции и паттернов GoF (Strategy, State, Decorator, Adapter).
  • Forwarding vs True Delegation: В Java практически всегда используется Forwarding (без передачи this). True Delegation требует передачи this в метод помощника.
  • Производительность: private final Delegate delegate полностью инлайнится JIT-компилятором C2 до уровня прямого машинного кода (0 накладных расходов).

Чего избегать (Red Flags):

  • ❌ Утверждать, что делегирование всегда медленнее наследования (при мономорфном inlining JIT разница равна нулю).
  • ❌ Допускать циклы взаимного делегирования (риск StackOverflowError).
  • ❌ Выставлять ссылку на внутренний изменяемый делегат через геттер (утечка инкапсуляции).

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