Learn Design Patterns

After ages putting this off, I’m now halfway through Head First Design Patterns: 9 down, 5 to go (with another 9 less commonly used patterns summarised in the final chapter).

Fail! But I’ll keep going.

From Design Patterns Explained (ch 14):

Extend software’s capabilities without changing it

Software clearly needs to be extensible. However, making changes to software runs the risk of introducing problems. This dilemma led Bertrand Meyer to propose the open-closed principle (OCP).[2] To paraphrase this principle, the modules, methods, and classes should be open for extension, while closed for modification.[3] In other words, design your software so that you can extend its capabilities without changing it.

[2] Meyer, B., Object-Oriented Software Construction, Upper Saddle River, NJ: Prentice Hall, 1997, p. 57.

[3] See this book’s Web site at http://www.netobjectives.com/dpexplained for a link to The Open-Closed Principle, an excellent article by Robert C. Martin.

As contradictory as this may sound at first, you have already seen examples of it. In the Bridge pattern, for instance, it is quite possible to add new implementations (that is, to extend the software) without changing any of the existing classes. In essence, the open-closed principle means to design our software so new functionality can be added in separate, distinct modules, with the integration cost being minimal.

It’s usually not possible to follow the open-closed principle completely; but as a goal, it is the right thing to be aiming for. The more my code follows the OCP, the easier my life will be later on when I have to accommodate new (and perhaps unforeseen) requirements.

Also explained by Uncle Bob, http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

It’s a simple static class which helps in creation of new objects. A factory is injected (or passed through a constructor), and then used to get new objects, as required. It’s useful, because you can actually change a factory at runtime.

Here’s an abstract factory example (from Design Patterns Explained):

abstract class ResFactory {
abstract public DisplayDriver getDispDrvr();
abstract public PrintDriver getPrtDrvr();
}

class LowResFact extends ResFactory {
public DisplayDriver getDispDrvr() {
return new LRDD;
}
public PrintDriver getPrtDrvr() {
return new LRPD;
}
}

class HighResFact extends ResFactory {
public DisplayDriver getDispDrvr() {
return new HRDD;
}
public PrintDriver getPrtDrvr() {
return new HRPD;
}
}

You have 2 different factories and both can be used interchangeably; the client doesn’t know or care which one it has. It has the same interface.

... the focus of my carrer.

My favorite pattern is visitor, probably because its one of the few patterns that I never came up on my own, before learning about patterns. There were a period when I went pattern-crazy.

Now I don’t use patterns everyday and everywhere. Its only sometimes.

One of the most useful and most elegant design patterns. You can have watchers for an object - observers - that get notified if any event happened—to the subject they’re interested.

The subject, object being observed, contains a list of registered watchers. If an event occurs, the list is traversed, and the watchers are notified if something happens.

Memento’s main objective is to preserve state and have the ability to restore it.

It’s intent, as the GoF book states, is “without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later.”

The Head First book says that in Java you could use Serialization to preserve object’s state.

One of the extra advantages of the Iterator is that, besides encapsulating the data structure and only exposing the iteration part, is that it allows you to create more than one iterator on the same aggregate, ie, create filters on the data.

Or it could be called “Dictator.” :-)

This pattern centralizes the control to the mediator, or director. Each object has a reference to the mediator and if the object changes, it notifies the mediator. Mediator in turn, might call other objects to update themselves.

The GoF book’s example is a set of widgets. The mediator has a reference to all of them, and each of the widgets have a reference to the director. If a widget changes, for instance if the user types some text, the widget notifies the director. The director then, calls a dependent widget to modify itself.

This pattern introduces low coupling in an otherwise high coupling situation. Each widget has to talk to only one object, as opposed to having to talk to many. This pattern breaks many-to-many relationship to one-to-many.