Yet another series of design patterns in C#? Has the world not seen enough dry and thoughtless regurgitations of the GoF? Yes and no.
What started out as a thoughtful attempt to categorize good principles of software design by a roving band of computer scientists named the “Gang of Four” has turned into the poster child of the Bloated Code movement. Vexilla Regis prodeunt Inferni. Decorators and Observer patterns for all!
While analyzing and classifying good patterns of software development is, in and of itself, a noble aspiration, unthinking application of those patterns is not. Many beginning software designers may implement an extraneous pattern simply because they like programming and think it neat. Injudicious pattern implementation causes as many problems as design patterns try to solve, resulting in code that is even more difficult to maintain and support.
In addition, while the original book’s authors focused on applications of the patterns, most design pattern adaptations focus on the conceptual code without the use-cases and implementation notes. The examples in the book could also use a refresher course – the technology that drives software applications has developed so tremendously over the past twenty years, that making references to Steve Job’s unsuccessful NeXTSTEP operating system make punch cards look trendy. Also, while the benefits provided by pattern implementation were readily touted in the initial book, twenty years of problems caused by poor pattern implementation can provide a fresh outlook on the ambitious work.
And just as past works from Plato’s Republic to Aesop’s Fables used relatable characters and problems to bring their stories and morals to life, so a good design pattern overview should focus on common tasks that programmers encounter in their daily work. Whether it’s the design of a caching system, to user authorization, to form validation, design patterns achieve usefulness through their application. As Machiavelli rightly would judge – design patterns are not an end, but rather a means to an end. Join us in future articles of this series where we dive into C# design patterns, hopefully without a single reference to a “ConcreteFactory” (unless the factory actually manufactures concrete).
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+
