Following up on the Observer/Event Pattern, it’s time for the third pattern, the Decorator Pattern.
The definition: "Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality."
Read more at http://blog.cumps.be/design-patterns-decorator-pattern/
Yesterday I described the Observer Pattern and mentioned that the .NET CLR provides this functionality through events and delegates.
Let’s have a look on how to implement this right now.
Read more at http://blog.cumps.be/design-patterns-observer-event-pattern/
Yesterday we saw the Strategy Pattern. Today I want to talk about the Observer Pattern.
First, the definition again: "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."
Read more at http://blog.cumps.be/design-patterns-observer-pattern/
The first pattern I want to talk about is the Strategy pattern, which always reminds me about the Command & Conquer games so I’ll simply use it as an example :)
First of all, the definition: "Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."
I’m bad at remembering definitions or trying to imagine what they really mean, so let’s just go ahead and try to create something and learn as we go, eventually we’ll end up implementing the Strategy pattern and you’ll 'get it' for the rest of your life, without a definition.
Read more at http://blog.cumps.be/design-patterns-strategy-pattern/