Builder Factory возвращает разные субинтерфейсы

Один из способов избежать приведения типов - определить единственный абстрактный метод, возвращающий T:

abstract class BaseFruitBuilder<T extends FruitBuilder<T>> implements FruitBuilder<T> {

    String taste;

    T taste(String taste) {
       this.taste = taste;
       return returnThis();
    }

    protected abstract T returnThis();

     //...
}

class GrapseBuilderImpl extends BaseFruitBuilder<GrapesBuilder> {
    //...
    @Override
    protected T returnThis() {
        return this;
    }
}

Обратной стороной является то, что вы должны доверять каждому подклассу для правильной реализации метода. Опять же, с вашим подходом ничто не мешает кому-либо объявить подкласс GrapesBuilder extends BaseFruitBuilder<AppleBuilder>, поэтому вам нужно в некоторой степени доверять подклассам.

ИЗМЕНИТЬ. Только что понял, что на это решение ссылается @ user158037 комментарий. Я сам использовал это, но никогда не понимал, что это известная идиома. :-)

Вы используете то, что обычно называют самотипами, но, кажется, несколько сбивает с толку то, что означает T. У вас есть FruitBuilder интерфейс с универсальным типом T, который должен представлять тип, который вернет построитель. Вместо этого вы, кажется, используете его для представления типа самого строителя, что, вероятно, не обязательно (если это так, см. Ниже более сложное предложение).

Будьте осторожны и осторожны с дженериками; тот факт, что это абстрактные понятия, легко сбивает их с толку. В вашем случае я бы предложил следующий интерфейс:

interface FruitBuilder<F extends Fruit> {
  FruitBuilder<F> taste(...);
  FruitBuilder<F> shape(...);
  FruitBuilder<F> weight(...);
  F build();
}

Отдельные строители теперь объявляют тип, который они в конечном итоге построят, а не свой собственный:

interface FruitBuilderFactory {
  GrapesBuilder grapes(); // define a concrete subtype to add methods
  FruitBuilder<Apple> apple();
}

И теперь каждый FruitBuilder явно является построителем F экземпляров, и каждый из ваших методов построения может чисто возвращать this, а ваш build() метод вернет объект ожидаемого универсального типа, позволяя вам написать что-то вроде:

Grape grape = FruitBuilderFactory.grape()....build();

Для большинства шаблонов строителей подклассов это все, что вам нужно. Даже если вам нужно определить дополнительные методы построения для определенных типов, вы все равно можете использовать эту структуру. Рассмотрим _11 _ и ImmutableMultiset.Builder<E>, расширяющий его и предоставляющий дополнительные методы. Также обратите внимание, что они связывают построитель напрямую с типом, а не с общим классом построителя-фабрики. Подумайте о том, чтобы воспроизвести эту структуру самостоятельно (например, Grape.Builder, Apple.Builder и т. Д.).

В редких случаях вам действительно нужно использовать собственные типы и также представлять построитель как универсальный тип. Это создает сложную структуру типов, но на практике проявляется в определенных местах, таких как Truth _ 15_ (который имеет значительно более сложную семантику, чем большинство строители). Обратите внимание, что у него есть два универсальных шаблона; S представляет себя, а T представляет тип, с которым действительно работают. Если ваш FruitBuilder должен быть таким сложным, вы должны использовать аналогичный шаблон:

interface FruitBuilder<B extends FruitBuilder<B, F>, F> {
  B taste(...);
  B shape(...);
  B weight(...);
  F build();
}