yes creating a static method can make sense (and I have seen other similar implementations resorting to static methods).

However, as you correctly noted, my approach is to use the builder through an interface which rules out static methods. I might post some more on this.

yes creating a static method can make sense (and I have seen other similar implementations resorting to static methods).

However, as you correctly noted, my approach is to use the builder through an interface which rules out static methods. I might post some more on this.

yes creating a static method can make sense (and I have seen other similar implementations resorting to static methods).

However, as you correctly noted, my approach is to use the builder through an interface which rules out static methods. I might post some more on this.

yes creating a static method can make sense (and I have seen other similar implementations resorting to static methods).

However, as you correctly noted, my approach is to use the builder through an interface which rules out static methods. I might post some more on this.

var myTeam = TeamBuilder.CreateTeam(“Chelsea”)
.WithNickName(“The blues”)
.WithShirtColor(Color.Blue)
.FromTown(“London”)
.PlayingAt(“Stamford Bridge”);

As I think about this though, I realize this would make it difficult to abstract TeamBuilder to the ITeamBuilder interface; so there is a tradeoff.

var myTeam = TeamBuilder.CreateTeam(“Chelsea”)
.WithNickName(“The blues”)
.WithShirtColor(Color.Blue)
.FromTown(“London”)
.PlayingAt(“Stamford Bridge”);

As I think about this though, I realize this would make it difficult to abstract TeamBuilder to the ITeamBuilder interface; so there is a tradeoff.

thank you for stepping by and leaving a comment.

The way I see it, a creational pattern such as the builder is always going to be somehow coupled to the object(s) it’s creating. The goal of creational patterns make clients more independent on how an object is composed.

The example that I have shown here is admittedly very simple. I have some implementations of this pattern where all the clients see is an interface (think of ITeamBuilder) which builds object implementing an interface (think ITeam).

In such a scenario, I can make both concrete ITeamBuilder and ITeam implementations invisible to the clients (e.g. by marking the classes and their constructor as internal). This is serving well for me to decouple the clients from the actual implementation.

thank you for stepping by and leaving a comment.

The way I see it, a creational pattern such as the builder is always going to be somehow coupled to the object(s) it’s creating. The goal of creational patterns make clients more independent on how an object is composed.

The example that I have shown here is admittedly very simple. I have some implementations of this pattern where all the clients see is an interface (think of ITeamBuilder) which builds object implementing an interface (think ITeam).

In such a scenario, I can make both concrete ITeamBuilder and ITeam implementations invisible to the clients (e.g. by marking the classes and their constructor as internal). This is serving well for me to decouple the clients from the actual implementation.

e.g. Query.createQuery().andName(“Chelsea”).list();

The drawback I see with the solution you are proposing is that TeamBuilder, if used without implicit user-defined type conversion operator, which AFAIK is unavailable in other languages such as Java, replicates all attributes of Team, which in turn could cause maintainability issues.

Could TeamBuilder subclass Team to actually avoid this? It would also have the advantage of permitting a private constructor for both Team and TeamBuilder…