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.
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.