Sunday, February 28, 2010

Tools

Given that I like Rich Internet Applications (both to write and to use), here is a list of tools that I really like. I need to say though, that as much as I like these tools, I can't seem to ever break away from the habit of using my desktop tools instead. I don't necessarily find the desktop tools any better (usually), but when I want to write a document I reach for Word first. Is that an indication of the ultimate future of RIA's? When even a person that believes fully in the technology doesn't make it a habit to use them?

This list isn't just RIA applications though...

Gliffy - drawing tool
SlideRocket - Presentations (although these people made me mad... so I probably won't use it - it is still pretty nice technology)
Buzzword - Word Processing... now all bundled together under Acrobat which also has presentations and spreadsheet functions
YUML - Create UML diagrams
Files2U - Send large files to others by uploading to this service - very nice





Design Patterns: Decorator and Proxy

Continuing the search to find just the right way to describe the difference between the Proxy and the Decorator patterns. The best one I've found so far is here. To summarize... the Proxy pattern establishes the target object at compile time while the Decorator pattern establishes the target at run time. This allows the Decorator pattern to also be nested many levels as the target object (being either the original target or a decorated target) is passed in to the decorator as a parameter. The Proxy would be a single level deep as the target is instantiated inside the proxy itself.

Saturday, February 27, 2010

Design Patterns: Decorator vs Chain of Responsibility

I am teaching a class this weekend on Design Patterns and the students are recognizing that many of the patterns start to look alike. Since the patterns rely on good OO principles like coding to the interface, then this is true.

However, someone was asking for a more detailed description of the differences between the Chain of Responsibility and Decorator patterns. I gave them my take on it but decided to do a little research on the topic.

Admittedly, this was very little research and I still believe my original answer holds true...
I believe that the biggest difference is that the client should have no idea that a Decorator is being used as opposed to the target object. However, they certainly know if they are using a Chain of Responsibility because the target object is passed along the chain.
I don't think that the primary difference is that the chain can be stopped at any point in the Chain of Responsibility structure while it must proceed to the target object in the Decorator. Would that mean that any Decorator "wrapper" that does not call the next Decorator (or Target) is no longer a Decorator? What if I'm decorating an object to perform some kind of security check and not allow access to the target object?

I do agree that there are similarities in that they both contain a "HAS-A" and an "IS-A". However, the "IS-A" for the decorator must be the same as the target object while the Chain of Responsibility is not.

Then we turned our attention to the Decorator and the Proxy and there again are the similarities. Both must implement the same interface as the target object. But the Decorator has an instance of it's parent type while the Proxy has an instance of the target object. Does that just imply that Decorators can be nested while a Proxy can not?

Continuing to search for these answers...