Избегаем беспорядка в конструкторе при внедрении зависимостей

Существует распространенная проблема, которую часто сталкиваются разработчики, использующие внедрение зависимостей (Dependency Injection, DI) в Java. Причина этой проблемы — увеличение количества параметров в конструкторе класса, когда внедряются новые зависимости.

Вот типичный пример такого кода:

public class MyClass {
    public MyClass(Service1 service1, Service2 service2, Service3 service3, ...) {
        ...
    }
}

С увеличением количества зависимостей, конструктор начинает разрастаться, что делает код менее читаемым и труднее для поддержки. Возникает вопрос: почему бы не использовать контейнер внедрения зависимостей и не сократить количество параметров до одного?

public class MyClass {
    public MyClass(Container container) {
        ...
    }
}

Но такой подход имеет свои недостатки.

Во-первых, он сводит на нет главное преимущество DI: явное указание зависимостей. Когда в конструкторе указаны все зависимости, можно легко увидеть, от чего зависит данный класс, и какие ресурсы ему требуются для работы. Если же все зависимости скрыты за контейнером, это становится неясным.

Во-вторых, это приводит к нарушению принципа единственной ответственности. Вместо того, чтобы просто создавать объекты, контейнер начинает контролировать их жизненный цикл, что может привести к непредсказуемому поведению.

Решение этой проблемы может быть использование паттернов проектирования, таких как Builder или Factory. Они позволяют инкапсулировать процесс создания объекта и управлять его зависимостями, не перегружая конструктор большим количеством параметров.

public class MyClassBuilder {
    private Service1 service1;
    private Service2 service2;
    ...

    public MyClassBuilder withService1(Service1 service1) {
        this.service1 = service1;
        return this;
    }

    public MyClassBuilder withService2(Service2 service2) {
        this.service2 = service2;
        return this;
    }

    ...

    public MyClass build() {
        return new MyClass(service1, service2, ...);
    }
}

Такой подход делает код более читаемым и поддерживаемым, сохраняя при этом преимущества внедрения зависимостей.