This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: AOP and the decorator pattern
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Found the new AOP article on msdn via Jimmy's entry and wondered: How far can you go with the decorator pattern before you need to step up to AOP? The decorator pattern being that which gives us pseudo multiple inheritence, best used for creating more specific behaviors of objects, done by wrapping with a class that implements the same interface. In the example from msdn, ObedientDog would inherit from Dog, and be able to wrap Dog. Thus, in order to create an ObedientPoodle, we would do something like this: Dog d = new ObedientDog(new Poodle()); ObedientDog could then override the method Heel, which an ordinary Poodle would just ignore, creating a Poodle that actually behaved like an obedient dog. But fiction aside, does anyone have an example of how they used AOP where decorators wouldn't suffice?...
Previous Topic
