Builder pattern vs. Dependency Injection (for instance via Guice)

Question

I'm developing a simple tree-structured database and I'm usually setting dependencies or optional settings via a Builder (Builder pattern). Now I'm not sure when to use for instance Guice, when to use the Builder pattern and when to use a static factory method instead of the constructor itself. I've read Effective Java several times and I think it mentions at least a lot of advantages for not exposing the constructor. It's time to reread ;-)

So, do you know of cases which are clearly distinguishable? And shouldn't I expose the constructor? Thus for instance in every case write public static Foo getInstance(...) { return new Foo(...)}?

Answer 1

Builder pattern vs. Dependency Injection

How are these 2 even close to comparable in your mind?
The builder pattern is used when you need to deal with classes whose constructors would have an overwhelming number of parameters (potentially optional) and this pattern makes your code easier to read and write.

Dependency Injection is an approach that facilitates loose coupling removing the dependencies of higher level classes to lower level classes. E.g. a class that needs to connect to a database does not directly create a connection but a connection is "injected" and this connection could be swapped to a different database without affecting the code using it.

Answer 2

I'm a firm believer in that you don't need to use dependency injection for everything.

• For a LookupService it would be natural inject a Dictionary such that its implementation can be swapped out by configuration.

• For a Firewall on the other hand. It would be natural for it to create its own FireWallRules, perhaps through a supplied Factory or a Builder.

As a guideline, inject what you need to configure, don't automatically inject everything else.

---

Consider a static factory (*) when

• named construction logic is desired. E.g., Lists.newArrayList()
• the construction is so complicated it doesn't belong in the class itself
• no configuration of the factory is required, and the factory has no side effects

Consider instance factories when

• there is complex instantiation logic
• configuration of the factory is needed
• using AbstractFactory design pattern
• there's need to create additional objects throughout the programs lifecycle

Consider a builder when

• there are complex parameter choices. E.g., 5 parameters where some are optional.

---

(*) Static methods are not always testable and the presence of one should in my opinion always be motivated. A typical usecase for a factory is to decrease coupling. By using a static factory that ability is completely lost.