Posts Tagged ‘Development’

Decorator Pattern

Monday, March 9th, 2009

In our ongoing series about design patterns, we introduce the Decorator Pattern. The decorator pattern serves to add specific functionality to an existing class. The classic example of this is in GUI programming, when a widget needs a border, or graphic surrounding it. Not using the Decorator Pattern, one might just subclass out the widget class and add a border to the subclassed widget. This becomes more difficult however, when there are multiple classes of widgets. This becomes almost impossible when dealing with a collection of widgets.

So, enter the Decorator Pattern. (more…)

Observer Pattern

Tuesday, March 3rd, 2009

One of my favorite design patterns, is the Observer Pattern. The Observer Pattern is used far more often then you might realize. The Observer Pattern is quintessential, for instance, in most GUI applications. Most applications that respond to key strokes, mouse clicks, or network updates use Observer Pattern. The idea, is that some object in the application is observable, and it has other objects that observe it.

It’s a lot like a bunch of soldiers waiting for the order to charge. The general is observable, and the soldiers are observers. When the general gives an order, the soldiers react in a way appropriate to the order. This is the essence of the Observer Pattern. Here’s the class diagram of the situation : (more…)

Factory Pattern

Sunday, March 1st, 2009

In following the theme of design patterns we’re starting this site off with, we’re talking about the Factory Pattern here. The Factory Pattern, true to it’s name, acts as a factory to produce objects depending on the parameters provided to it.

A common example of this are configuration objects. Suppose you’ve setup a configuration for you’re application to use an XML configuration file to run. Now, let’s say for some unknown reason, you need to use an INI file for configuration. Or, let’s say that today you’re using MySQL for database storage, but tomorrow, you might be forced to use Oracle.

Having to find where you create the instances of classes could be difficult, or maybe even impossible. The solution to this dilemma, is to use factory pattern to produce objects where any future ambiguity might cause a disaster.

Typically, the way a factory is implemented is to implement some sort of class that acts as a quasi-gateway to the object that’s needed. To keep things simple, we’ll assume we’re trying to get a database object and we need to not worry about the actual implementation of the database (more…)