Why is a Pattern different from other forms of guidance?


The Microsoft Solution Engineering Team in which I work has just started its own blog – so I wrote my first post on the subject of reintroducing patterns and the qualities associated with a good pattern. Here is an abstract from the blog post…


Why is a pattern different from other forms of guidance?


For this first weeks post I am going to focus on the topic of why a pattern is different from other guidance. This seems extremely timely because there are a large number of books / white papers / guidance hitting the press most of which will confuse the concepts listed below – and leave you no better off when the next major paradigm shift occurs – and leave you feeling like you have to relearn everything you thought you already knew.


 


When asked what a pattern is the standard answer you will get from a pattern geek is something along these lines:


     “A pattern is a proven solution to a problem, described in context”


 


As a one liner this is reasonable – but it doesn’t really help you understand what the qualities of a pattern are that separate them from other forms of guidance – nor does it help you discern a good pattern from a bad pattern. 


 


Considerations when Writing and Reviewing Patterns


Here are a couple of considerations that I look for when writing or reviewing patterns.



  • Actual Solution. A pattern describes an actual solution to a problem – it isn’t just an abstract principle
  • Based on Proven experience. The solution is based on proven experience – ie it is something that has been tried, tested and refined over a number of solutions at a number of different organizations
  • Platform Independent. The solution is described in a platform independent manner – ie independent of implementation – hence it is durable. This would allow the same logical solution to be considered regardless of what version of a platform you are running on, or potentially even what platform you are running on.

    • Note that the pattern on its own may not be useful to many folks – which is why many pattern guides will have a separate piece of guidance demonstrating how to implement that pattern on a specific platform – thus increasing the relevance and applicability for that pattern.
    • patterns & practices used to call these implementation patterns – I personally think a “How To” style of document is sufficient.

  • Include Tradeoffs. Patterns should include architectural tradeoffs that you must consider when selecting the pattern

    • The forces that steer you towards using the pattern or away from using the pattern
    • Benefits and considerations that you must consider if you do apply the pattern
    • Relationships to other patterns that might be good substitutes or might well be used in addition to this pattern

  • Atomic. Patterns are also typically atomic – following the Single Responsibility principle. If you see a pattern solving a number of problems it is usually a sign that the pattern should have been split into multiple patterns.
  • Named. And of course the pattern has a name, that if well thought out will establish a vocabulary for our industry.

Comments (4)

  1. Matthew Adcock says:

    Looking forward to more posts…

    Regards,

    Matthew

  2. I grew up in both Australia and New Zealand – a long way from the US and the UK where home computing

  3. I grew up in both Australia and New Zealand – a long way from the US and the UK where home computing

  4. I grew up in both Australia and New Zealand – a long way from the US and the UK where home computing