It looks as though there are still a lot of software developers out there that just don't "get it" when it comes to design patterns. When I was interviewing architects and senior developers, I would always ask "are you familiar with design patterns, and if so, how would you describe the value in applying them to your work?". For the most part, I got no answer, or a textbook answer without much behind it. I guess that shouldn't be too surprising. I picked up the "Gang of Four" book several times before I understood patterns, each time saying "this time I'm going to get it". I never did; I never did; or at least not by reading the book anyway. I finally "got it" while designing an application a couple of years ago. This was an application that I knew would eventually have to be extended to handle "new stuff". I started sketching out my design, and as I did so, I remembered some things I had read about "factories" and "commands", and how they relate to pattern basics. Suddenly those ideas made sense and guided me through a design that stood up to extension. Now that I understand pattern basics and how they apply to my design, I get a lot more out of reading about new patterns.
This article is intended to be very fundamental as it applies to patterns. Anyone who has a basic or strong understanding of the importance and appropriate use of patterns will probably not learn anything new. This article is directed at the developer who has heard about patterns or read about them and finds himself or herself saying, "I just don't get it". If that describes you and you are willing to give this article careful thought, I'm confident that this will be a turning point for you. I believe we can make the light bulb go on by taking a simple problem and doing it the "wrong" way, and then the "right" way.
So if you think you have something to learn about design patterns, then on to the example...
There are a slew of design patterns out there. Let's look at one of the basics: the factory. A factory class commits to return an object of a base class (or interface). The object returned by the factory will actually be a subclass of that type. The calling program will treat that object in the generic manner (as defined by the base class), and the object will demonstrate specific functionality (of the extended class). These statements will become clearer after we've stepped through the example. You may want to read this paragraph again, once you have a better understanding of the approach.