facet-builder example : removing redundant construction of Person objects for each sub-factory

[CodedByATool]

The facet-builder is a nice pattern. However in the example, having the PersonBuilder instantiate an addition Person object for each sub-factory seemed non-intuitive when you just need a single owner at an outer-scope to the fluent evaluation.

I suggest removing Person p; member from PersonBuilder, renaming PersonBuilder to BasePersonBuilder, and adding a new derived class called PersonBuilder that has the Person p; member and passes a reference to its base class in the constructor (the only new method).

As a result only one Person object is constructed, one move-Construct, one destroy of a moved object, and one final destruction of the owning person at program end occurs. Regardless of how many sub-factories are created.

Unless you see a flaw in this approach; I would suggest changing the example in a similar way for the benefit of anyone borrowing the pattern implementation and implementing their own version with many more sub-factories on objects with potentially non-trivial default construction.

Regards.

[nesteruk]

Thanks for the pointer, you are absolutely right about this, there's useless duplication happening here. I'll do some experiments as to how to propagate the constructed object better and will update the source code when I come up with something palatable.

On 17 August 2016 at 04:16, CodedByATool [email protected] wrote:

The facet-builder is a nice pattern. However in the example, having the PersonBuilder instantiate an addition Person object for each sub-factory seemed non-intuitive when you just need a single owner at an outer-scope to the fluent evaluation.

I suggest removing Person p; member from PersonBuilder, renaming PersonBuilder to BasePersonBuilder, and adding a new derived class called PersonBuilder that has the Person p; member and passes a reference to its base class in the constructor (the only new method).

As a result only one Person object is constructed, one move-Construct, one destroy of a moved object, and one final destruction of the owning person at program end occurs. Regardless of how many sub-factories are created.

Unless you see a flaw in this approach; I would suggest changing the example in a similar way for the benefit of anyone borrowing the pattern implementation and implementing their own version with many more sub-factories on objects with potentially non-trivial default construction.

Regards.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nesteruk/DesignPatternsWebinar/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcoNmeVTi_JSGIgFbvP8FD-WHuyFgFLks5qgmEJgaJpZM4JmAKp .

Dmitri Nesteruk [email protected] skype: dmitri.nesteruk