Software By JeffMain Page | About | Help | FAQ | Special pages | Log in
The Free Encyclopedia
Printable version | Disclaimers

Thoughts on Design Patterns

From Software By Jeff

In a recent discussion there was a conversational chasm driven by two camps of software developers. The first were whole-hearted, dyed-in-the-wool, patterns-save-the-day evangelists. The other were patterns-have-a-place, get-the-job-done, algorithm-over-fretting-over-pattern-names, self-proclaimed software realists.

For the record, I consider myself part of the second group, 'though perhaps not so strongly as some of the others in my camp during the discussion. I firmly maintain that I can intelligently apply a pattern without knowing its name, and that given a pattern, I can ensure that it is used when creating software.

Design Patterns, to be sure we speak of the same thing, found favor in the mid-1990s after the acceptance of a book of a similar name. The book lays out some good principals to be used when designing object-oriented software. The idea behind the book, since adapted by many other authors, is that using patterns helps convey the ideas behind the different methods of getting things done. It explains the reasons for decisions made while authoring software, and provides mechanisms for recalling and reusing similar ideas for other software projects.

The use of patterns happens whether you know the names of them or not. If you've ever created an Interface in Java, it can be argued that you've applied a Facade Pattern. If you've ever used Java Beans it can also be argued that you've used a Visitor Pattern. If you've ever written a switch statement, you could say that you've used a Controller Pattern.

Now, the idea that you must use patterns in designing the software smacks of restrictions should one not be completely familiar with all of the options. To say up front that one must use a Facade seems counter-productive, as it may not make sense to create an interface should the design be simple and something not expanded. The corollary to that is that if the design is extending existing functionality, it could behoove the developers to refactor the existing work to use a Facade and introduce an interface to allow the new items to reuse existing code.

Similarly, a Visitor Pattern could be argued to be in application wherever a data structure is passed with the understanding that its data elements will be returned with potential modification. Is it necessary to declare that you're using such a pattern when in fact you're simply passing a variable by reference? I would suggest that it is not.

Some of the more complex patterns may make sense to declare in design. Preparing a Factory Pattern, for example, provides all manner of control of the instantiation of objects. Perhaps there's a pool or synchronization behind the Factory that allows something robust or secure. Factories are good things, and are frequently used by libraries and developers starting from "scratch." Surely, though, if one were to make a method that returned an instance of an object, they'd be using a Factory even if it hadn't been declared such.

Do we do these things all of the time? Absolutely.

Are we using patterns and not knowing it? Quite possibly.

Does that make us lesser developers 'cause we're not thinking of some defined name before we start to do some logical work? That's just foolish.

Does it make someone else better 'cause they'll start out by proclaiming a pattern to use before they finish their design? Arguably, and I argue "not at all."

Retrieved from ""

This page has been accessed 8283 times. This page was last modified 20:42, 21 Jan 2008.

Main Page
Community portal
Current events
Recent changes
Random page
Edit this page
Editing help
This page
Discuss this page
Post a comment
Printable version
Page history
What links here
Related changes
My pages
Create an account or log in
Special pages
New pages
Image list
Bug reports