This article discusses the phenomena of Software Design Patterns and starts by drawing parallels from the dress making pattern books of the post-war years.
In the 1950’s it was quite usual for women of all ages to peruse dress pattern books searching for a new dress. The world was still recovering from the second World War, Rationing of clothing in the UK had ended in 1949 and there was little in the way of ‘off the peg’ clothing. Dress patterns had been around for years and are still available today, but they have gone on-line (Simplicity, McCall).
As mass-production of clothing commenced and prosperity returned, the pattern book was replaced by the pages of the mail-order catalogue; but more on this parallel later.
After selecting a pattern and purchasing appropriate material, many women would sit for hours behind a sewing machine to form their new creation. Wealthier women could afford to engage the services of a (semi-) professional seamstress with the most privileged engaging in Haute Couture.
Whatever the method of production, this approach had one redeeming feature over the mass-produced ‘off the peg’ garments we have now; the garments were unique. Although two products might have been based on the same pattern (like bride’s maids dresses) they were usually made to measure and could be customised to a degree. More adventurous and skillful (largely) women threw the pattern books out the window and designed their own fashions, which enabled them to express their own ideas.
So, this all very well but what the heck does it have to do the Software Development? Well, they follow a similar process; design, develop, test and re-factoring. Even within testing there was Verification (check to ensure the product matched the design) and Validation (check to ensure the product fit the customer’s needs (body shape and intended function)). But let’s focus on the design aspect and use of those pattern books.
OOD and the Gang of four
In the mid 90’s, as the software development paradigm began to shift from Procedural to Object-Orientated Programming (OOP) languages, it was becoming obvious that too many developers, learning on the job as so many of us have do, we’re making a complete hash of OOP. For many seasoned programmers the paradigm shift felt quite extreme and the tools left a lot to be desired.
Even some of the younger crew struggled with concepts such as inheritance and encapsulation, especially if not from a computer science background. I personally witnessed some travesties where the developer thought that inheritance imposed encapsulation so all objects had to be progeny of a single base object. In some languages there is the concept of Object as the foundation of all, but that should not be the basis from which to develop a solution.
It was obvious that before too long some clever people were going to have to propose a methodology for Object-Orientated Design (OOD); enter stage-left the “Gang of Four”. Messrs Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with their influential book Design Patterns: Elements of Reusable Object-Oriented Software. This masterpiece documented 23 classic design patterns with examples is C++ and Smalltalk but the concept of using Design Patterns for Software Engineering was far from a new idea in 1994.
For the origins of Design Patterns we have to look to the buildings Architect Christopher Wolfgang Alexander, who’s writings were essential reading for Computer Scientist during the 1960’s and ~70’s. His ideas continue to influence modern software development methodologies such as Extreme Programming.
Far be it for me to question the wisdom of such aforementioned intellectual giants and I genuinely respect the invaluable contribution they have made to Computer Science and Software Engineering. But, I can’t help thing that Software Design Patterns have the potential to stifle creativity if employed formulaically, just like the ‘off the peg’ clothes filling the rails of stores.
Wikipedia (the font of all knowledge, right!) gives a good description of Software Design Patterns as “… a general reusable solution to a commonly occurring problem …”. It does not state “… a general purpose solution to all past, present and future problems …”. Yet some Software Engineers turn to the book from the off before trying to formulate an original design of their own.
I am sure the Gang of Four never intended their great work to be used in this prescriptive manner. Do people really think there will be no other efficient patterns for OO other than the 23 already identified. If designers turn immediately to Book they will never discover new patterns. I am not suggesting we throw the Book out the window, never to darken the designer’s door again – far from it. The Book is a wealth of vital learning and should be used to validate your thinking, seek optimisation of your design and avoid anti-patterns (introduced problems or constraints to the solution). The nature and hazards presented by anti-patterns are discussed in the book “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”, written by the “Upstart Gang of Four”: William Brown, Raphael Malveau, Skip McCormick and Tom Mowbray.
I think considering Design Patterns (and Anti-Patterns) when preparing a candidate architecture of application design is wise, but on once you have attempted some original thought considering the specific requirements defining the problem. Don’t automatically expect the Gang of Four to offer the panacea and don’t automatically assume the 23 patterns are to be all and end all.