View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Discussion 2 - Benjamin McMillan

Part 1
3. How does choice of language affect the use of design patterns?

http://www.python.org/workshops/1997-10/proceedings/savikko.html
http://www.cs.ubc.ca/labs/spl/papers/2002/oopsla02-patterns.pdf (Section 6.1)
http://www.norvig.com/design-patterns/ppframe.htm

Of course, not all languages are built the same. For some, OO was an afterthought (PHP), while for others, it was the initial goal (Smalltalk). Different languages vary in flexibility and features when working with OO designs, including patterns.

Norvig uses the term "invisible" to describe patterns that are already so much a part of a language, where there is no real need to explicitly implement the pattern. By using Lisp, Norvig argues, most of the "Gang of Four" patterns become invisible, which means that Lisp is a great language for using those patterns. Savikko, however, explains that Python, although object oriented, lacks certain features which can cause the implementation of certain patterns to be unelegant. For instance, because Python can't have private constructors, you might have to use throw an exception in the constructor - something many will think to be bad style. On the other hand, the implementation Savikko provides for the Chain of Responsibility pattern enhances the pattern due to Python's runtime capabilities (being able to query and modify stuff while running). In other words, your choice of language will affect how straight forward it will be, if at all possible, to implement certain design patterns. Sometimes you might have to hack around limitations of the language, other times the language will already provide an easy implementation.

Part 2
Facade Pattern:

http://c2.com/cgi/wiki?FacadePattern
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/tutorial.html
http://en.wikipedia.org/wiki/Facade_pattern

The Facade pattern is acts very much like an Adapter pattern, but mostly for groups of objects. An Adapter pattern is sort of a wrapper for a single object, to "adapt" the interface for that object to something compatible or easier to use for an object accessing the object (through the adapter). The Facade pattern is an extension of this in that it adapts the interfaces of multiple objects into one interface.

If class A (the client) wants the system to do action A and thus calls the facade class's method for action A, and is not concerned with the fact that action A involves methods from classes B-E. The facade worries about that stuff. Sometimes a facade is useful for providing an easy interface to an overly complicated or poorly designed subsystem. Facades are also great allowing extensibility while maintaining stability. If you add a module to the subsystem, all you need to do is update the appropriate methods within the facade.

There seem to be several ways for handling how to setup the facade. One way is to instantiate the facade, and have the facade then instantiate the objects it's adapting. Or you could instantiate a facade and register your existing modules with it as they are instantiated by you. Another way is to let the modules you're wanting to adapt to create the facade (or look for a compatible facade) and somehow provide you access to it.

I find this pattern interesting because it can greatly improve an existing system. If I were to be assigned to a working, but hard to access system, I could see myself quickly building a facade to the system, and thereafter accessing that facade. Additionally, building a facade after-the-fact could help critique the existing system. In order to figure out which methods you want the facade to contain, you must outline the responsibilities of the system. Hopefully, by implementing the methods of the facade, one could expose which interfaces of the underlying objects need improvement.

One downside I see to facades is the ability for layering - one could wrap poorly written objects in several facades, provide a facade for those facades, and so on. Although this might be convenient, facades might be used as an easy way out - an excuse not to design the systems well in the first place. However, sometimes even well designed systems are more complicated than the intended client objects want.

In fact, I can think of an example project where I use facades. I designed a web architecture so that the user created pages creates and communicates with a template object. The template object, then, understands the rest of the system, and delegates responsibility accordingly. For example, the user create page calls "listArticles" of the facade, and the facade then calls on the Article object, as well as calling on a few other modules to provide the Article object with contextual information, and to perform other functionality (like the CSS and HTML objects for generating the table to contain the list of articles). I didn't want to concern the user with calling all of those methods, of modules I didn't want the user to know about.

My profile: Benjamin McMillan

Link to this Page