Правильный полиморфный билдер на Java / Хабр

О чем все это?

При реализации chained builder на Java все прекрасно, пока не понадобится добавить наследование. Сразу же возникают две проблемы — как сделать, чтобы методы родительского билдера возвращали объект дочернего билдера и как передавать дочерний билдер в функции, принимающие родительский. Предлагается реализация паттерна, которая позволяет решить обе проблемы. Исходники можно посмотреть здесь на гитхабе.

Upd. Реальная проблема

В приложении есть dto-объекты для отображения результата, которые строятся следующим образом:

1) Создается билдер нужного dto-объекта.
2) Билдер передается в различные классы по цепочке, каждый класс использует билдер для установки нужных ему полей.

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

Постановка задачи

Тут должно быть 100500 слов о важности паттерна билдер, дабы не утомлять читателя этой лабудой, сразу перейдем к делу. Пусть есть 3 класса с понятными именами Gen1, Gen2 и Gen3. Они образуют линейную иерархию Gen3 → Gen2 → Gen1. Каждый их них содержит ровно один очень важный метод с именем setValX (где X цифра из имени класса). Мы хотим получить билдеры Builder1, Builder2, Builder3 каждый из которых содержит соответствующий метод valX, который реализуется только у одного класса (не хотим копипастить).

Так же должны работать цепочки:

Gen1 gen1 = builder1.val1("val1").build();
Gen2 gen2 = builder2.val1("val1").val2("val2").build();
Gen3 gen3 = builder3.val1("val1").val2("val2").val3("val3").build();

И возможность использовать дочерние билдеры вместо родительских:

Gen1 someFunction(Builder1 builder1) {
    return builder1.val1("val1111");
}
...
someFunction1(builder3.val2("val222").val3("val333"));

Что и как получилось

Билдер предполагается сделать по следующей схеме — создать объект в самом начале, потом заполнить его поля, а в функции build() вернуть клиенту. В этом случае нам необходим класс, который будет делать простую вещь — хранить ссылку на достраиваемый объект и хранить ссылку на тот билдер нужного типа, который будут возвращать все методы-установщики значений. Следующий класс решает проблему:

public class BuilderImpl<T, RetBuilder>  {
    protected T nested;
    RetBuilder returnBuilder;

    protected BuilderImpl(T child) {
        nested = child;
    }

    protected T getNested() {
        return nested;
    }

    protected void injectReturnBuilder(RetBuilder builder) {
        returnBuilder = builder;
    }

    protected RetBuilder self() {
        return returnBuilder;
    }

    public T build() {
        return nested;
    }
}

Конечно, от метода injectReturnBuilder лучше было бы избавиться, передавая нужные данные в конструктор, но увы, туда будет передаваться this дочернего билдера, который нельзя использовать до окончания родительского конструктора super(). Метод getNested() на любителя, можно обращаться к полю nested напрямую. Метод self() сделан, чтобы не путать поле со словом this.

Теперь задумаемся вот над какой проблемой. Если у нас есть некий генерик Builder1<> который реализуется все что нам нужно для класса Gen1 (с какими-то параметрами Gen1,Builder1), на нужно будет унаследовать от него генерик Builder2 для Gen2 (с какими-то параметрами Gen1,Builder1), а от того Builder3 для Gen3 то получится, что у Builder3 в предках две реализации исходного Builder1 с разными параметрами, что, увы прямо запрещено Java.

Но выход есть — надо разделить настройку полей объекта и создание объекта на разные классы.
Классы с именами InnerBuilderX отвечают за настройку полей и возврат объекта и допускают наследование. Классы с именами FinalBuilderX наследуются от соответствующих InnerBuilderX, добавляя создание исходного объекта и к дальнейшему наследованию не допускаются.

Отдельную трудность представляет написание InnerBuilderX с правильной комбинацией wildcard. Путем долгих проб и ошибок (читать спецификации не наш путь) был найдет приемлемый вариант. Но пока он был найден — были перепробованы комбинации, на который инспектор Idea помирал или ошибался, что несколько затормозило разработку. И так, вот код для InnerBuilder1 класса Gen1. Параметр T это тип хранящегося объекта, RetBuilder — тип билдера, который возращается из функции установки val1.

public static class InnerBuilder1<T extends Gen1, RetBuilder extends InnerBuilder1<? extends T, ?>> 
extends BuilderImpl<T, RetBuilder> {

        protected InnerBuilder1(T created) {
            super(created);
        }

        public RetBuilder val1(String val) {
            getNested().setVal1(val);
            return self();
        }
    }

Конечно, рекурсивная конструкция class InnerBuilder1<T extends Gen1, RetBuilder extends InnerBuilder1<? extends T, ?>> немного напрягает, но зато реально работает.

Ну а FinalBuilder довольно простой:

private static class FinalBuilder1 extends InnerBuilder1<Gen1, FinalBuilder1> {

        private FinalBuilder1() {
            super(new Gen1()); // сюда нельзя this
            injectReturnBuilder(this);
        }
    }

Осталось добавить статическую функцию по созданию билдера:

public static InnerBuilder1<? extends Gen1, ?> builder() {
        return new FinalBuilder1();
}

Теперь перейдем к дочернему билдеру. Нам унаследовать реализацию для внутреннего билдера и сделать создание объекта в финальном:

public static InnerBuilder2<? extends Gen2, ?> builder() {
        return new FinalBuilder2();
    }

    public static class InnerBuilder2<T extends Gen2, RetBuilder extends InnerBuilder2<? extends T,?>> extends InnerBuilder1<T, RetBuilder> {

        protected InnerBuilder2(T created) {
            super(created);
        }

        public RetBuilder val2(String val) {
            getNested().setVal2(val);
            return self();
        }
    }

    private static class FinalBuilder2 extends InnerBuilder2<Gen2, FinalBuilder2> {

        private FinalBuilder2() {
            super(new Gen2());
            injectReturnBuilder(this);
        }
    }

Можно попробовать скомпилировать тестовый код:


Gen2.builder().val1("111").val1("111").val1("111").val1("111").val2("222").build();

Получилось! А что там с полиморфизмом?


 //  принимает билдер передкового Gen1
 Gen1 buildGen1Final(Gen1.InnerBuilder1<? extends Gen1, ?> builder) {
        builder.val1("set value from Gen1 builder");
        return builder.build();
    }
...
// а получает билдер потомка Gen2
 buildGen1Final(
        Gen2.builder().val2("set value from Gen2 builder")
 );

Все тоже работает. Аналогично реализуется билдер для класс Gen3, за подробностями можно обратится в гитхаб