О чем все это?
При реализации chained builder на Java все прекрасно, пока не понадобится добавить наследование. Сразу же возникают две проблемы — как сделать, чтобы методы родительского билдера возвращали объект дочернего билдера и как передавать дочерний билдер в функции, принимающие родительский. Предлагается реализация паттерна, которая позволяет решить обе проблемы. Исходники можно посмотреть здесь на гитхабе
Постановка задачи
Тут должно быть 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, за подробностями можно обратится в гитхаб
Автор: blaze79