Is it a good idea to return a Builder from a Factory?

As always, you can do what is best suited to your domain and concrete problem.

In any case, this looks like mixing a concrete factory with the Bloch builder pattern. In this case, I do not see the benefit of the factory, as you can just have it all wrapped up (including default values) in the builder and just use new EmpBuilder() // with Default Values. You could give the Builder some "static factory methods", e.g. EmpBuilder.default() // returns new EmpBuilder.

Note that this may be different if you use the abstract factory pattern, or the GOF builder pattern.

One more alternative: Use the factory with a configuration (config can be constructed using the Bloch builder):

 EmpFactory.get(new Config().withSalary(5000)); 

This could also work with the abstract factory then.

Or just use the factory by passing in the parameters:

 EmpFactory.get(/* salary: */ 5000); 

A Factory normally returns different implementations of a class/interface, while a builder gives a fluent interface for configuring a single type.

So if you factory returns a builder you might expect it to return different builder types? which doesn't sound like what you want.

I think it would be fine to have a builder with a GetDefault() method and not worry about a factory at all

var builder = new EmployeeBuilder(); var employee1 = builder.Default().Build(); var employee2 = builder.Default().WithSalary(200).WithName("bob").Build(); 

With a Bloch Builder you get the default values like this:

//Get a fully configured Employee with default values Employee employee = employeeBuilder.build(); 

If that blows up, it doesn't offer default values.

//Get a fully configured builder with default values, but change only the salary //before finally building the Employee Employee employee = employeeBuilder.setSalary(5000).build(); 

Where this gets interesting is when you have more than one set of "default" values. In that case the sets of values need names.

EmployeeBuilder internBuilder = employeeBuilder.setSalary(5000); 

This gives you a builder that defaults to intern employee values. You can send this off to other code that will set other settings before finally building it.

EmployeeBuilder grantExecutiveAccess(EmployeeBuilder employeeBuilder){ return employeeBuilder .setExecutiveBathroomKey(true) .setParkingPermit("A") ; } 

Here the name of these "defaults" is executive access. This way if another set of "defaults" becomes relevant you just need to give them a name.

Now was that a factory? Doesn't look like a typical one. It takes the same type as it returns. It returns what it was passed after mutating it. Call it a shunt if you like.

If there was such a thing as an executive intern employee you could build them like this:

EmployeeBuilder internBuilder = employeeBuilder.setSalary(5000); Employee executiveIntern = EmployeeFactory .grantExecutiveAccess(internBuilder) .build() ; 

The key lesson here is that builders are first class objects themselves. So you are perfectly allowed to pass them around.

As to whether this is a good idea, you have to admit this leaves you with a fair bit to digest. The charm of builders is that they are straight forward to use. If you're going to require mixing factories and builders when a flat builder with some extra keyboard typing solves the same problem you'd better have a problem complex enough to make that a poor choice. Having the ability to decouple intern construction code from executive construction code is nice. But do you really need it this badly?

The advantage of this method over adding some executive method to the builder is that adding the factory will leave the builder code untouched. Sometimes that's important. Just remember, you could also create a whole new builder. Just need a good name.

It should also be noted that when you take a Bloch Builder beyond just simulating named arguments you're heading into DSL territory. DSLs are very powerful but take a fair bit of work to set up. They should be reserved for cases where they will be used a lot to make up for that extra effort.

The reason you don't see this sort of thing happening is because the builders are used when we want the caller to specify details of the implementation being created, and factories are used when we do not want the caller to specify details of the implementation.

If you really have some kind of situation where you don't want the caller to know the implementation class, but you still want to provide the callers with a standard interface for setting up a whole bunch of implementation details, then what you're doing is OK, but unusual.

It looks to me, though, like there's a good chance that your use of either the factory or the builder pattern is misguided. Why are you using a factory? Why are you using a builder?

Factory method design pattern definition according to wikipedia it is:

In object oriented programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.

Builder design pattern definition according to wikipedia it is:

The builder pattern is a design pattern designed to provide a flexible solution to various object creation problems in object-oriented programming. The intent of the builder design pattern is to separate the construction of a complex object from its representation.

Concluding when instances of interfaces or base classes implemented or extended by classes that require a complex instantiation or initialisation then yes returning a builder from a factory it is a suitable approach, worthless to say...

EmployeeFactory.constructive().salary(...).employ(); 

...is readable while...

Emplyee employee = new Employee(); employee.setSalary(...); ... 

...although is readable has a jerky narative.

Otherwise, sure, it is not a proper construction to return a builder from a factory just to implement some design patterns.