生成器模式和继承

2022-08-31 12:48:51

我有一个对象层次结构,随着继承树的加深,复杂性会增加。这些都不是抽象的,因此,它们的所有实例都或多或少地用于复杂的目的。

由于参数的数量非常高,因此我希望使用生成器模式来设置属性,而不是编写多个构造函数。由于我需要满足所有排列,因此继承树中的叶类将具有伸缩构造函数。

当我在设计过程中遇到一些问题时,我在这里浏览了一个答案。首先,让我给你一个简单,肤浅的例子来说明这个问题。

public class Rabbit
{
    public String sex;
    public String name;

    public Rabbit(Builder builder)
    {
        sex = builder.sex;
        name = builder.name;
    }

    public static class Builder
    {
        protected String sex;
        protected String name;

        public Builder() { }

        public Builder sex(String sex)
        {
            this.sex = sex;
            return this;
        }

        public Builder name(String name)
        {
            this.name = name;
            return this;
        }

        public Rabbit build()
        {
            return new Rabbit(this);
        }
    }
}

public class Lop extends Rabbit
{
    public float earLength;
    public String furColour;

    public Lop(LopBuilder builder)
    {
        super(builder);
        this.earLength = builder.earLength;
        this.furColour = builder.furColour;
    }

    public static class LopBuilder extends Rabbit.Builder
    {
        protected float earLength;
        protected String furColour;

        public LopBuilder() { }

        public Builder earLength(float length)
        {
            this.earLength = length;
            return this;
        }

        public Builder furColour(String colour)
        {
            this.furColour = colour;
            return this;
        }

        public Lop build()
        {
            return new Lop(this);
        }
    }
}

现在我们有一些代码要继续,成像我想构建一个:Lop

Lop lop = new Lop.LopBuilder().furColour("Gray").name("Rabbit").earLength(4.6f);

此调用不会编译,因为无法解析最后一个链接的调用,无法定义方法。因此,这种方式要求所有调用都以特定顺序链接,这是非常不切实际的,特别是对于深层层次结构树。BuilderearLength

现在,在我搜索答案的过程中,我遇到了一个Java Builder类的子类,它建议使用奇怪的递归泛型模式。但是,由于我的层次结构不包含抽象类,因此此解决方案对我不起作用。但是这种方法依赖于抽象和多态性来发挥作用,这就是为什么我不相信我能适应我的需求。

我目前采用的一种方法是覆盖层次结构中超类的所有方法,只需执行以下操作:Builder

public ConcreteBuilder someOverridenMethod(Object someParameter)
{
    super(someParameter);
    return this;
}

通过这种方法,我可以确保返回一个可以发出链调用的实例。虽然这并不像伸缩反模式那样糟糕,但它是紧随其后的,我认为它有点“黑客”。

对于我的问题,是否有其他我不知道的解决方案?优选与设计模式一致的解决方案。谢谢!


答案 1

这当然可以通过递归绑定来实现,但子类型生成器也需要是泛型的,并且您需要一些临时抽象类。它有点麻烦,但它仍然比非通用版本更容易。

/**
 * Extend this for Mammal subtype builders.
 */
abstract class GenericMammalBuilder<B extends GenericMammalBuilder<B>> {
    String sex;
    String name;

    B sex(String sex) {
        this.sex = sex;
        return self();
    }

    B name(String name) {
        this.name = name;
        return self();
    }

    abstract Mammal build();

    @SuppressWarnings("unchecked")
    final B self() {
        return (B) this;
    }
}

/**
 * Use this to actually build new Mammal instances.
 */
final class MammalBuilder extends GenericMammalBuilder<MammalBuilder> {
    @Override
    Mammal build() {
        return new Mammal(this);
    }
}

/**
 * Extend this for Rabbit subtype builders, e.g. LopBuilder.
 */
abstract class GenericRabbitBuilder<B extends GenericRabbitBuilder<B>>
        extends GenericMammalBuilder<B> {
    Color furColor;

    B furColor(Color furColor) {
        this.furColor = furColor;
        return self();
    }

    @Override
    abstract Rabbit build();
}

/**
 * Use this to actually build new Rabbit instances.
 */
final class RabbitBuilder extends GenericRabbitBuilder<RabbitBuilder> {
    @Override
    Rabbit build() {
        return new Rabbit(this);
    }
}

有一种方法可以避免使用“混凝土”叶类,如果我们有这个:

class MammalBuilder<B extends MammalBuilder<B>> {
    ...
}
class RabbitBuilder<B extends RabbitBuilder<B>>
        extends MammalBuilder<B> {
    ...
}

然后,您需要使用菱形创建新实例,并在引用类型中使用通配符:

static RabbitBuilder<?> builder() {
    return new RabbitBuilder<>();
}

这是有效的,因为类型变量上的绑定确保了例如 具有 的返回类型,即使类型参数只是一个通配符。RabbitBuilderRabbitBuilder

不过,我不太喜欢这样,因为您需要在任何地方都使用通配符,并且您只能使用菱形或原始类型创建新实例。我想无论哪种方式,你最终都会有点尴尬。


顺便说一句,关于这个:

@SuppressWarnings("unchecked")
final B self() {
    return (B) this;
}

有一种方法可以避免这种未经检查的强制转换,即使方法抽象:

abstract B self();

然后在叶子类中覆盖它:

@Override
RabbitBuilder self() { return this; }

这样做的问题在于,尽管它对类型更安全,但子类可以返回除 .基本上,无论哪种方式,子类都有机会做错事,所以我真的看不出有什么理由更喜欢其中一种方法而不是另一种方法。this


答案 2

面对同样的问题,我使用了 emcmanus 提出的解决方案:https://community.oracle.com/blogs/emcmanus/2010/10/24/using-builder-pattern-subclasses

我只是在这里重新复制他/她喜欢的解决方案。假设我们有两个类,和 。 继承自 。ShapeRectangleRectangleShape

public class Shape {

    private final double opacity;

    public double getOpacity() {
        return opacity;
    }

    protected static abstract class Init<T extends Init<T>> {
        private double opacity;

        protected abstract T self();

        public T opacity(double opacity) {
            this.opacity = opacity;
            return self();
        }

        public Shape build() {
            return new Shape(this);
        }
    }

    public static class Builder extends Init<Builder> {
        @Override
        protected Builder self() {
            return this;
        }
    }

    protected Shape(Init<?> init) {
        this.opacity = init.opacity;
    }
}

有内部类,它是抽象的,还有内部类,这是一个实际的实现。在实现时将非常有用:InitBuilderRectangle

public class Rectangle extends Shape {
    private final double height;

    public double getHeight() {
        return height;
    }

    protected static abstract class Init<T extends Init<T>> extends Shape.Init<T> {
        private double height;

        public T height(double height) {
            this.height = height;
            return self();
        }

        public Rectangle build() {
            return new Rectangle(this);
        }
    }

    public static class Builder extends Init<Builder> {
        @Override
        protected Builder self() {
            return this;
        }
    }

    protected Rectangle(Init<?> init) {
        super(init);
        this.height = init.height;
    }
}

要实例化 :Rectangle

new Rectangle.Builder().opacity(1.0D).height(1.0D).build();

同样,这是一个抽象类,从 继承自 ,而 a 是实际实现。每个类都实现该方法,该方法负责返回其自身的正确转换版本。InitShape.InitBuildBuilderself

Shape.Init <-- Shape.Builder
     ^
     |
     |
Rectangle.Init <-- Rectangle.Builder

推荐