Question

Is the use of multicast delegates an appropriate way to implement the Builder design pattern?

The reason I ask is because my concept/understanding of the Builder pattern is a collection of methods that can be combined/rearranged like LEGO blocks. So you might have the following methods:

void Shave(int StrokeCount) { ... }
void FeedTheDog(int Cups) { ... }
void MakeCoffee(int Cups) { ... }
void Shower(int Temperature) { ... }

…that can be mixed-and-matched/LEGO’d together, so that one morning you call:

Shower()
FeedTheDog()
MakeCoffee()

…another morning:

Shower()
Shave()
FeedTheDog()
MakeCoffee()

…another morning:

MakeCoffee()
FeedTheDog()
Shower()

(etc. &c. ad infinitum ad nauseum)

And since multicast delegates allow you to add same-signatured methods to an instance of the delegate, and they will fire in the order you add them, there seems to be a semantic connection here (in my mind/to my current way of thinking, anyway). I may be wrong, though, that’s why I ask.

Answer 1

I don’t really see the advantage of using multicast delegates for the Builder pattern unless you wanted to defer the method execution for some reason. I have never had this requirement but that’s not to say it couldn’t be useful. If you had a scenario where one class was responsible for “preparing the recipe” and another for “cooking the recipe”, I guess it could be useful. Even then, though, you would be limited to only using methods that have the same signature. This is just my opinion though.