A Pattern is as a Pattern Does

I had a great conversation the other day with Mike McKinney.  One topic in particular really stuck with me and now I can't seem to shake it.  Mike and I had been talking about design philosophies and what it takes to do smart implementation, especially as a government contractor.  We both lamented the environment of design and implementation bloat in which we seemed to find ourselves.  Bloat does not fly in government contracting.  Time and money resources are extremely tight and skillsets are scarce.  Mike noted that "ever since the 'Gang of Four' book came out everyone thinks they are an architect and everyone wants to build a framework."  I couldn't have agreed more.  Ugh, that word:  "framework."  I've used it many times myself, but if I never see or hear or use it again I wouldn't be unhappy about it.

The purpose of design patterns isn't necessarily to build huge, abstract libraries of software components.  The purpose of design patterns isn't necessarily to solve common programming problems for other programmers.  A wonderful thing about design patterns is that they are something familiar to rely on when confronted with new problems.

I've used dozens of patterns and I've even participated in writing a  framework or two.  But the world needs only so many frameworks.  At the same time there are no shortages of hard problems to solve for which design patterns are quite, quite useful.  I don't have time, money, or expertise for all the frameworks I'd otherwise need to get the job done.  I need robust, reliable patterns and people skilled enough to recognize how to implement them to solve customers' problems.

So, attention all developers:  Don't just think of design patterns as architectural building blocks. Sure, they are that.  But think also of design patterns as tools in a toolbox.  

When we're confronted with a domain-specific problem we should build neither point-to-point solutions nor frameworks.  Instead, use patterns to solve a domain-specific problem in a reliable way.  Point-to-point solutions require niche skillsets, are complicated, and don't scale well.  Yet, we don't have time or resources to build frameworks and there wouldn't be much of a market for them if we did.  Either that or our frameworks have to be raised up to such a level of abstraction that we end up forcing domain-specific stakeholders into our patterns rather than molding our patterns around domain-specific use cases.

So, what is a good example of how we use patterns to solve domain-specific problems without building a framework?  ETLV is a good example:

You don't need a framework to implement this pattern.  Simply recognize that the solution to interoperability among domain-specific applications is the production and consumption of well-formed Unicode data.  If someone gives you a data source and is looking for a way to visualize it you could look for a visualization API and use point-to-point integration to read the data and constuct objects from the API.  But then what do you do when someone hands you another data source?  What if the new source lends itself to a new visualization technique?  What if the API you chose the first time around doesn't support that technique?  Well, perhaps you have job security as a software integrator.  On the other hand, if you want to maintain separation of concerns and implement a robust, flexible solution you could follow a pattern based on decoupling data from proprietary or domain-specific formats and transforming data into views using standard, ubiquitous processors.  This effectively changes the integration and interoperability problem into a easier-to-solve scalability problem.  Point-to-point integration is neither simple nor scalable.  However, given any data source expressed as well-formed Unicode we can write a practically boundless number of transformations to produce a practically boundless number of views and applications.  It takes a pattern but not a framework.