Builder pattern for polymorphic object hierarchy: possible with Java?

14,726

Solution 1

The solution I imagine is like the Curiously Recurring Template Pattern, or CRTP. You can define a base class to handle the parent-related initialization, but you still may find the two boilerplate getParent() and getThis() methods to be too much repetition in each derived child-related builder class.

Take a look:

abstract class ParentBase implements Parent
{
  @Override
  public final Long getParentProperty()
  {
      return parentProperty_;
  }


  protected void setParentProperty(Long value)
  {
      parentProperty_ = value;
  }


  private Long parentProperty_;
}


abstract class ParentBuilder<T extends ParentBuilder<T>>
{
  T withParentProperty(Long value)
  {
      getParent().setParentProperty(value);
      return getThis();
  }


  protected abstract ParentBase getParent();


  protected abstract T getThis();
}


final class ConcreteChild1 extends ParentBase implements Child1
{
  @Override
  public Integer getChild1Property()
  {
      return childProperty_;
  }


  public void setChild1Property(Integer value)
  {
      childProperty_ = value;
  }


  private Integer childProperty_;
}


final class Child1Builder extends ParentBuilder<Child1Builder>
{
  public Child1Builder()
  {
     pending_ = new ConcreteChild1();
  }


  public Child1Builder withChild1Property(Integer value)
  {
      pending_.setChild1Property(value);
      return this;
  }


  @Override
  protected ParentBase getParent()
  {
      return pending_;
  }


  @Override
  protected Child1Builder getThis()
  {
      return this;
  }


  private final ConcreteChild1 pending_;
}

As you can see, the ParentBuilder type expects to be cooperating with a derived type to allow it to return a properly-typed instance. Its own this reference won't due, because the type of this within ParentBuilder is, of course, ParentBuilder, and not, say, Child1Builder as intended to maintain the "fluent" call chaining.

I owe the "getThis() trick" to Angelika Langer's tutorial entry.

Solution 2

I don't think getParent() and getThis() are necessary, if you're willing to accept the restriction that the withXXXProperty() methods be called from "youngest" to "oldest":

class Parent
{
    private final long parentProperty;

    public long getParentProperty()
    {
        return parentProperty;
    }

    public static abstract class Builder<T extends Parent>
    {
        private long parentProperty;

        public Builder<T> withParentProperty( long parentProperty )
        {
            this.parentProperty = parentProperty;
            return this;
        }

        public abstract T build();
    }

    public static Builder<?> builder()
    {
        return new Builder<Parent>()
        {
            @Override
            public Parent build()
            {
                return new Parent(this);
            }
        };
    }

    protected Parent( Builder<?> builder )
    {
        this.parentProperty = builder.parentProperty;
    }
}

class Child1 extends Parent
{
    private final int child1Property;

    public int getChild1Property()
    {
        return child1Property;
    }

    public static abstract class Builder<T extends Child1> extends Parent.Builder<T>
    {
        private int child1Property;

        public Builder<T> withChild1Property( int child1Property )
        {
            this.child1Property = child1Property;
            return this;
        }

        public abstract T build();
    }

    public static Builder<?> builder()
    {
        return new Builder<Child1>()
        {
            @Override
            public Child1 build()
            {
                return new Child1(this);
            }
        };
    }

    protected Child1( Builder<?> builder )
    {
        super(builder);
        this.child1Property = builder.child1Property;
    }

}

class Child2 extends Parent
{

    private final String child2PropertyA;
    private final Object child2PropertyB;

    public String getChild2PropertyA()
    {
        return child2PropertyA;
    }

    public Object getChild2PropertyB()
    {
        return child2PropertyB;
    }

    public static abstract class Builder<T extends Child2> extends Parent.Builder<T>
    {
        private String child2PropertyA;
        private Object child2PropertyB;

        public Builder<T> withChild2PropertyA( String child2PropertyA )
        {
            this.child2PropertyA = child2PropertyA;
            return this;
        }

        public Builder<T> withChild2PropertyB( Object child2PropertyB )
        {
            this.child2PropertyB = child2PropertyB;
            return this;
        }
    }

    public static Builder<?> builder()
    {
        return new Builder<Child2>()
        {
            @Override
            public Child2 build()
            {
                return new Child2(this);
            }
        };
    }

    protected Child2( Builder<?> builder )
    {
        super(builder);
        this.child2PropertyA = builder.child2PropertyA;
        this.child2PropertyB = builder.child2PropertyB;
    }
}

class BuilderTest
{
    public static void main( String[] args )
    {
        Child1 child1 = Child1.builder()
                .withChild1Property(-3)
                .withParentProperty(5L)
                .build();

        Child2 grandchild = Child2.builder()
                .withChild2PropertyA("hello")
                .withChild2PropertyB(new Object())
                .withParentProperty(10L)
                .build();
    }
}

There's still some boilerplate here: the anonymous concrete Builder in each builder() method, and the super() call in each constructor. (Note: that assumes that every level is designed for further inheritability. If at any point you have a final descendant, you can make the builder class concrete and the constructor private.)

But I think this version is easier to follow, for the next programmer who comes along and has to maintain your code (no self-referential generics, for starters; a Builder<X> builds Xs). And IMHO requiring the child properties to be set on the builder before the parent properties is as much an advantage, in terms of consistency, as it is a disadvantage in terms of flexibility.

Solution 3

Here is a solution that uses generics.

public abstract class ParentBuilder<T extends ParentBuilder<T>> {
    private long parentProperty;

    protected abstract T self();

    public T withParentProperty(long parentProperty) {
        this.parentProperty = parentProperty;
        return self();
    }

    protected static class SimpleParent implements Parent {
        private long parentProperty;

        public SimpleParent(ParentBuilder<?> builder) {
            this.parentProperty = builder.parentProperty;
        }

        @Override
        public Long getParentProperty() {
            return parentProperty;
        }
    }
}
public final class Child1Builder extends ParentBuilder<Child1Builder> {
    private int child1Property;

    private Child1Builder() {}

    public static Child1Builder newChild1() {
        return new Child1Builder();
    }

    @Override
    protected Child1Builder self() {
        return this;
    }

    public Child1Builder withChild1Property(int child1Property) {
        this.child1Property = child1Property;
        return self();
    }

    public Child1 build() {
        return new SimpleChild1(this);
    }

    private final class SimpleChild1 extends SimpleParent implements Child1 {
        private int child1Property;

        public SimpleChild1(Child1Builder builder) {
            super(builder);
            this.child1Property = builder.child1Property;
        }

        @Override
        public Integer getChild1Property() {
            return child1Property;
        }
    }
}
public final class Child2Builder extends ParentBuilder<Child2Builder> {

    private String child2propertyA;
    private Object child2propertyB;

    private Child2Builder() {}

    public static Child2Builder newChild2() {
        return new Child2Builder();
    }

    @Override
    protected Child2Builder self() {
        return this;
    }

    public Child2Builder withChild2PropertyA(String child2propertyA) {
        this.child2propertyA = child2propertyA;
        return self();
    }

    public Child2Builder withChild2PropertyB(Object child2propertyB) {
        this.child2propertyB = child2propertyB;
        return self();
    }

    public Child2 build() {
        return new SimpleChild2(this);
    }

    private static final class SimpleChild2 extends SimpleParent implements Child2 {
        private String child2propertyA;
        private Object child2propertyB;

        public SimpleChild2(Child2Builder builder) {
            super(builder);
            this.child2propertyA = builder.child2propertyA;
            this.child2propertyB = builder.child2propertyB;
        }

        @Override
        public String getChild2PropertyA() {
            return child2propertyA;
        }

        @Override
        public Object getChild2PropertyB() {
            return child2propertyB;
        }
    }
}

For larger hierarchies or ones where concrete classes aren't just at the leaves, it is necessary to extract part of the above concrete builders into an intermediate abstract class. For instance, Child1Builder could be split into the following two classes Child1Builder and AbstractChild1Builder, of which the latter could be extended by yet another child builder.

public abstract class AbstractChild1Builder<T extends AbstractChild1Builder<T>> extends ParentBuilder<T> {

    protected int child1Property;

    public T withChild1Property(int child1Property) {
        this.child1Property = child1Property;
        return self();
    }

    protected final class SimpleChild1 extends SimpleParent implements Child1 {
        private int child1Property;

        public SimpleChild1(AbstractChild1Builder<Child1Builder> builder) {
            super(builder);
            this.child1Property = builder.child1Property;
        }

        @Override
        public Integer getChild1Property() {
            return child1Property;
        }
    }
}
public final class Child1Builder extends AbstractChild1Builder<Child1Builder> {
    private Child1Builder() {}

    public static AbstractChild1Builder<Child1Builder> newChild1() {
        return new Child1Builder();
    }

    @Override
    protected Child1Builder self() {
        return this;
    }

    public Child1 build() {
        return new SimpleChild1(this);
    }   
}

Solution 4

maybe like this without builders?:

interface P {
    public Long getParentProperty();
}
interface C1 extends P {
    public Integer getChild1Property();
}
interface C2 extends P {
    public String getChild2PropertyA();
    public Object getChild2PropertyB();
}
abstract class PABC implements P {
    @Override public final Long getParentProperty() {
        return parentLong;
    }
    protected Long parentLong;
    protected PABC setParentProperty(Long value) {
        parentLong = value;
        return this;
    }
}
final class C1Impl extends PABC implements C1 {
    protected C1Impl setParentProperty(Long value) {
        super.setParentProperty(value);
        return this;
    }
    @Override public Integer getChild1Property() {
        return n;
    }
    public C1Impl setChild1Property(Integer value) {
        n = value;
        return this;
    }
    private Integer n;
}
final class C2Impl extends PABC implements C2 {
    private String string;
    private Object object;

    protected C2Impl setParentProperty(Long value) {
        super.setParentProperty(value);
        return this;
    }
    @Override public String getChild2PropertyA() {
    return string;
    }

    @Override public Object getChild2PropertyB() {
        return object;
    }
    C2Impl setChild2PropertyA(String string) {
        this.string=string;
        return this;
    }
    C2Impl setChild2PropertyB(Object o) {
        this.object=o;
        return this;
    }
}
public class Myso9138027 {
    public static void main(String[] args) {
        C1Impl c1 = new C1Impl().setChild1Property(5).setParentProperty(10L);
        C2Impl c2 = new C2Impl().setChild2PropertyA("Hello").setParentProperty(10L).setChild2PropertyB(new Object());
    }
}
Share:
14,726

Related videos on Youtube

Riley Lark
Author by

Riley Lark

Using GWT + GAE to make ActiveGrade. BS in Computer Science and Math, worked as an SDE at Microsoft, programmed for the University of Maryland for 3 years, and taught math and science at Scattergood Friends School from 2005-2010. I was the director of Shiloh Quaker Camp in Charlottesville, VA for three summers, and now I run a startup software shop making ActiveGrade! Email: riley at activegrade.com Twitter: rileylark

Updated on June 04, 2022

Comments

  • Riley Lark
    Riley Lark almost 2 years

    I have a hierarchy of interfaces, with Child implementing Parent. I would like to work with immutable objects, so I would like to design Builder classes that construct these objects conveniently. However, I have many Child interfaces, and I don't want to repeat the code for building Parents in each type of child builder.

    So, assume the following definitions:

    public interface Parent {
        public Long getParentProperty();
    }
    
    public interface Child1 extends Parent {
        public Integer getChild1Property(); 
    }
    
    public interface Child2 extends Parent {
        public String getChild2PropertyA();
        public Object getChild2PropertyB();
    }
    

    How can I efficiently implement builders Child1Builder and Child2Builder? They should support operation like:

    Child1 child1 = Child1Builder.newChild1().withChild1Property(5).withParentProperty(10L);
    

    and

    Child2 child2 = Child2Builder.newChild2().withChild2PropertyA("Hello").withParentProperty(10L).withChild2PropertyB(new Object());
    

    I don't want to implement a special case of withParentProperty for each child builder.

    Edited to add second property to Child2 to clarify that this cannot be done with simple generics. I am not looking for a way to combine Child1 and Child2 - I am looking for a way to implement a Builder system that does not duplicate the work of building the parent class for every child class.

    Thanks for any help!

    • Ivo
      Ivo about 12 years
      if the implementations of Child1 and Child2 inherits from the same one that also implements Parent, then you can have a parent Builder that has the method withParentProperty()
    • Riley Lark
      Riley Lark about 12 years
      Once you try the implementation you'll see that it's more complicated than this and you need something like seh provided below. If you can demonstrate a simpler implementation I'd love to see it!
  • Riley Lark
    Riley Lark about 12 years
    This would be a good way to implement Child1 and Child2 in this simple case, but it's not getting at the central focus of my question of efficiently implementing builders for these things without duplicate code. Generics in this way do not support the operations in my original post.
  • Perception
    Perception about 12 years
    Im pretty sure his point about generics is that you consolidate the bulk of your Child logic in one class, making it trivial to define the parent building logic once.
  • Riley Lark
    Riley Lark about 12 years
    No, this is just an example. In the actual scenario I cannot consolidate the bulk of my Child logic in one class. I want to have different classes that do different things, but have a common parent class.
  • Riley Lark
    Riley Lark about 12 years
    ah hah, the getThis() trick is the step I was missing! I don't mind the extra boilerplate - I just want to avoid having to duplicate (and maintain!) code for every field I add to the parent later. Thanks for the answer.
  • Riley Lark
    Riley Lark about 12 years
    This is a much simpler solution - thanks for writing! It produces mutable objects, which I'm trying to avoid, and still requires me to implement setParentProperty (for each parent property!) in each child object, so I think I may need something more complex.
  • Ray Tayek
    Ray Tayek about 12 years
    making the objects immutable will require two classes for each type of child. is that ok? can you live with an explicit constrictor and not do the set property chaining? can the properties be put in a map? - also, the implementation of setParentProperty in each child is only a few lines of code - the alternative in this case would be an ugly downcast
  • Riley Lark
    Riley Lark about 12 years
    The alternative that seh provided only requires one class for each child (after a few access-level tweaks) if those classes are in the same package as the builder, right? The implementation of setParentProperty in each child is only a few lines of code, but when I add/remove parent properties the maintenance costs get higher and higher. With five parent properties and eight child classes (my actual situation) that's 40 extra methods, so the extra getThis and getParent seh suggested are very light-weight in comparison. If I need to add a parent property, no change is required in the children.
  • Ray Tayek
    Ray Tayek about 12 years
    ok. consider using two maps: propertyNameToType and propertyNameToValue in parent and each child. build them easily and stick immutable maps in the classes that you expose to the users.
  • Ray Tayek
    Ray Tayek about 12 years
    no, the setter can check that the new value is of the proper type since we have the propertyNameToType map. using the getter requires a cast though.
  • Ray Tayek
    Ray Tayek about 12 years
    i posted another answer using maps, but you have to get the values like: c2.getChildProperty(C2.Names.x); and c2.getParentProperty(P.Names.d);
  • Riley Lark
    Riley Lark about 12 years
    Those are good points, David. I'm being a bit pedantic, perhaps, when I demand that I be able to call the setPropertyX methods in any order. The accepted answer is definitely hard to read.
  • Håvard Geithus
    Håvard Geithus almost 12 years
    There's a nice blog post on Java.net about a similar solution: weblogs.java.net/blog/emcmanus/archive/2010/10/25/… .
  • claya
    claya almost 10 years
    If you wanted to add another nesting of concrete subclass of Child1 e.g. Child2 and Child2Builder how would you declare Child2Builder and Child1Builders getThis method?
  • subrat71
    subrat71 almost 10 years
    Two things come to mind: neither class ConcreteChild1 nor Child1Builder could be final, and Child1Builder would need a type parameter to indicate the concrete type it builds, which could then be either ConcreteChild1 or your proposed ConcreteChild2. Since Java lacks default values for type parameters, this would make direct use of class Child1Builder more annoying. It might help to introduce an intervening abstract parameterized class that both Child1Builder and Child2Builder could extend.
  • claya
    claya almost 10 years
    @seh thanks for the insight. What would this intervening abstract class provide? the getThis()? it seems that would need to come from the instantiable builder classes not an abstract one. is it just for the type param for the classes? i.e. class Child1Builder extends ParentBuilder<AbstractChildBuilder>
  • LegendLength
    LegendLength over 6 years
    claya, After trying this out for a few months the only solution I can find is to make the intermediate classes abstract. So the class tree only has concretes at the leaves and nowhere else.