Design patterns are one of the areas of programming knowledge that I really should know, apparently. Throughout my career as a developer, numerous people have told me this much. I have attempted, perhaps as many times, to learn them from various sources (including my usual go-to resources: Head First and For Dummies). However, I've never quite managed to grasp the concepts presented therein; they seem strangely elusive and esoteric. However, since I am yet again without electricity (and quite often no Internet connection) or fixed employment, leaving me with time hanging heavy on my hands, I thought I'd give learning them another go. As much as I enjoy such activity, there is only so much Bill Bryson I can read and DS I can play before tiring of them, after all.

First up, I'm going to take another stab at Design Patterns for Dummies (published by Wiley in 2006), by Steve Holzner (author of at least one quality educational and informative book on PHP). Since I prefer the For Dummies books to the Head First ones, I'm leaving that second title for later. If I don't come right this time, then I think there's no hope of me ever succeeding with this particular set of knowledge. Perhaps I will need The Complete Idiot's Guide to Design Patterns, but that title doesn't exist, as far as I know (and I have looked). Maybe this text will become that. Without further ado, let's venture once more into the breach!

Introduction

From my experiences in development, I know that the same problems tend to come up fairly regularly (such as coding the logic for login, logout and registration pages). Recreating the same solution, with the same steps/algorithm, gets tedious fast. Like many developers, few things irritate me more than repeating myself. Why do something multiple times if it need only be done once? (After all, that's why we develop applications in the first place!) That's the idea behind design patterns: A design pattern is a design for a solution to a particular problem (or set thereof) commonly encountered during development, in much the same way as a sowing pattern is a guide for creating a particular item of clothing. Knowing the right pattern(s) can save developers a lot of time and effort (things of which we always seem to be short).

Gang of Four (GoF) Patterns

There are no shortage of patterns in the world of software development. Some are best-suited/particular to certain frameworks and/or paradigms. However, there are a standard set of twenty-three (23) generic design patterns created and documented by Erich Gamma, Richard Helm,
Ralph Johnson, and John Vlissides — whom have since been called the Gang of Four, or GoF (pronounced like someone with a speech impediment would say "goth"), for short. The patterns they describe can be found in their book, Design Patterns: Elements of Reusable Object-Oriented Software (published in 1995 by Addison Wesley). I find it to be a horribly confusing/impenetrable work of which I can't make head nor tail. Presumably others do too, given the plethora of books with titles such as Design Patterns Explained (which isn't particularly explanatory, in my opinion) and Design Patterns for Dummies. (If I can't learn it from a For Dummies book, I can't learn it.) This text covers those twenty-three standard patterns, since they have been thoroughly tested, have been found to be widely applicable and are a good starting point for an introduction to learning design patterns. It also covers some additional patterns, which have become popular in the years since the GoF patterns came into prominence. (Creating new patterns is a thing that happens, since the art and craft of software development evolves; they're not set in stone. MVC is a case in point.)

Grab a Cup or Two of Java

Design patterns, by themselves, tend to be quite abstract. To help cement the knowledge and ideas they encapsulate, explanations will often be accompanied by code that demonstrates their use. If you understand Java (or another C-based/inspired OOP language, such as C#), you should be fine. (I suggest that, after reading this conceptual guide/overview, you find a book that caters to your particular language of choice, such as C++ Design Patterns or Design Patterns in Java, etc. If you're using one of the more well-known and popular programming languages, that shouldn't be difficult to do.) I've also published a quick comparison of Java to C#, for developers familiar with one of the two languages. If you need that, have a look through my previous posts on this blog.

As much as I am not a fan of Java, for reasons I'm not mentioning here, it does have three particular advantages for demonstrating design patterns:

• It is object-oriented. Although it's not unfeasable to use some design patterns with (partially) procedural code (such as PHP), design patterns are predominantly used with the OOP paradigm, from what I understand.
• The way the language is designed and implimented, a number of things (such as closing GUI windows and event handling) *require* the use of design patterns when adding/implementing functionality in programs developed in/with it.
• It happens to be the language used in _Design Patterns for Dummies_. Since that book is my starting point and I've yet to read a book on design patterns in Python (which is a much easier language to understand and use, in my opinion), I'm not going to adapt the code to use a different language.

Good News: Your problem has already been solved!

"Months of development can save you days of design and planning!"

As a developer, you've probably encountered the problem that, without a good design, plan or overview up front (especially an undocumented one), you can often lose the bigger picture and get bogged down in the details of the implementation, especially when it's not clear how to solve a particular problem you're facing. I know I've certainly had that experience more than once. It doesn't result in elegant or robust code. At best, it will solve a particular problem in a particular way and prove functionally adequate for a while, but it's definitely far from optimal. It will likely need a rewrite in future, but nobody can say when that will be. That's not what you and your team members want, right? Problems that are solved badly have a nasty tendency to not stay solved for very long, compounded by the fact that much of development is spent on maintenance, extension and debugging. Trying to band-aid "fix" issues with kludges doesn't make a lot of sense in the long run, since it ends up costing a lot of time and effort.

Judicious use of design patterns (the key word being "design") helps to mitigate this problem by providing some degree of an overview/plan. Plus, by following standard naming conventions for classes that make use of specific patterns (for example, WidgetFactory and TaskListIterator), you can convey to other developers how a particular class/instance should work (not that that necessarily guarantees it does) without having to write lots of documentation comments. Design patterns, appropriately and properly implemented, simplify the process of software development. The caveat, of course, is not to try to force everything to fit a design pattern; adding unnecessary abstraction is something with which no developer needs to contend.

If it Fits, it Sits!

One of the perks of design patterns is that they make solutions that use them easily identifiable, understandable, extendable, maintainable and reusable (one of the goals of OOP). One of the problems prevalent in development is the tendency to create solutions that solve specific problems (programming to the problem), rather than in a way that makes a solution extensible, maintainable and reusable. This can lead to many hours being lost when further development is required (which it almost invariably is).

Design patterns are proven solutions to programming problems, but they're ones that automatically implement good design techniques.

Someone has already faced the problem situations you’re facing, solved them, and is willing to show you what the best techniques are. All you have to do is recognize which design pattern fits which situation and leverage it.

How's that for a sweet deal?

Enter the Gang of Four Patterns (and Some Newer Ones)

1995 was a while ago. As the development landscape has changed, it has become apparent that some of the standard twenty-three patterns, while useful, are not used as frequently or as widely as others. Some newer, arguable better, patterns have become popular since then. This text includes both the original twenty-three patterns (with emphasis on the commonly-used ones) *and* the newer patterns.

NB: Design patterns are about more than tailoring code to fit certain patterns, however helpful they may be. They are also about making use of good design insights and practices. OOP is a wonderful thing in many situations, but blindly applying the paradigm to a problem, without a view of the bigger picture, is a trap into which too many developers fall, causing as many problems as it solves. (If you've only got a hammer in your toolbox, you'll tend to treat every problem as a nail.)

That's all for now. In the next part, I will cover some specific design patterns, starting with the Mediator pattern. Yeah, I know, my multi-part tutorials tend to be rather long. At least this isn't Programming with Mosh, where he spends four hours explaining a concept that's worth only forty minutes.

Post thumbnail: Designed Universe courtesy of random-art.org