30

Many Builder Pattern examples make the Builder an inner class of the object it builds.

This makes some sense since it indicates what the Builder builds. However, in a statically typed language we know what the Builder builds.

On the other hand if the Builder is an inner class, you should know what class the Builder builds without looking inside of the Builder.

Also, having the builder as an inner class reduces the number of imports since it can be referenced by the outer class--if you care about that.

And then there are practical examples where the Builder is in the same package, but not an inner class, like StringBuilder. You know that the Builder should build a String because it is named so.

That being said, the only good reason I can think of for making a Builder an inner class is that you know what the class' Builder is without knowing its name or relying on naming conventions. For example, if StringBuilder was an inner class of String I probably would have known it existed sooner than I did (speculative).

Are there any other reasons to make the Builder an inner class or does it just come down to preference and ritual?

Improve this question

2 Answers 2

Reset to default
36

I think that the reason for doing this is so that the inner class (the Builder) can access private members of the class that it is building.

From http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html

Non-static nested classes (inner classes) have access to other members of the enclosing class, even if they are declared private.

...

Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be declared private. By hiding class B within class A, A's members can be declared private and B can access them.

...

As with instance methods and variables, an inner class is associated with an instance of its enclosing class and has direct access to that object's methods and fields.

Here's some code to try to illustrate this:

class Example { private int x; public int getX() { return this.x; } public static class Builder { public Example Create() { Example instance = new Example(); instance.x = 5; // Builder can access Example's private member variable return instance; } } }

As a static class, Builder doesn't have a specific instance of Example that it is tied to. However, given an instance of Example (or one that it creates itself) Builder can still access the private members of that instance.

Improve this answer
5
  • 1
    Great answer, that makes sense! However builder patterns usually have a static inner class and would only be able to access static private members of the outer class. If you had a builder for an instantiated class that would be all kinds of weird. Commented Jan 23, 2014 at 17:03
  • 1
    @Nathanial not at all, private instance variables are also accessible: ideone.com/7DyjDR Commented Jan 23, 2014 at 17:11
  • 2
    @nathanial: Yes, but the builder is not manipulating the class; it is manipulating an object of the class that the builder itself has instantiated. Commented Jan 23, 2014 at 17:31
  • @amon I see what you did there. Thanks for the explanation! Commented Jan 23, 2014 at 17:39
  • Specifically, it gives the builder access to a private constructor for the class being built, allowing that class to be immutable (all fields final) and only instantiable via the builder. Commented Jun 7, 2019 at 19:55
1

There is no "should" in this case. Defining a builder inside another class or having it separate is orthogonal to the Builder pattern. Many examples do this due to convenience of presenting the code in one consistent file (also for accessing private members but that depends on context as well). Feel free to do otherwise

Improve this answer
3
  • Not sure why this answer was down voted, for any other reason than, "because that's not how we do it in Java." The Builder Pattern provides a wrapper around a constructor that takes a bunch of parameters. If the constructor takes those parameters, then there is no need for the Builder object to access private members. Commented Jul 13, 2016 at 16:45
  • I agree. The question is wrong assuming "should". Further, it even assumes not having it nested requires the new type to be located in it's own source-code file - also false. Commented Jun 25, 2020 at 13:00
  • So the quetion could be would instead of should, but its the same question. It could be rephrased as When 'should' you... And while not explicitly stated, this is a java question. Obviously, if the constructor does not take those parameters, then you would need private access, so that answers your question. If one wants to design the class differently, then it should be constructed in a way to facilitate that and that is what I was I did not understand (and was explained) when I asked the original question. Commented Sep 1, 2020 at 18:37

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.