Pattern Specification vs. Pattern Implementation, which do I choose?
In the book we introduce the concept of a pattern implementation as an asset that “automates the application of a pattern in a particular environment.” In contrast, a pattern specification is the formal, written documentation that describes a pattern. With these two types of patterns available, you might wonder, should we replace all specifications by implementations? Is there still room for both? When use one or the other?
Thousands of specifications already exist, so we have a large pool that we can draw upon in solving problems. Existing specifications also provide us with samples that we can use and refer to as we create our own patterns. Most of us have already seen and worked with pattern specifications, so we have familiarity with the concept that we can leverage as we create our patterns. We generally know how a pattern specification is structured and the content that goes within. Traditionally, we’ve looked to use patterns only as specifications – but that is just part of the story.
The ability to find, create and then use pattern implementations is a key aspect of PBE. Today’s tooling is building out increasing capabilities to automate the patterns. Also, the PBE Patterns and Guidelines can help you build your own pattern implementations. However, don’t interpret this as an endorsement that all you need is pattern implementations – there is a need to bring together the right mix of pattern specifications and pattern implementations into a successful project. That mix will be determined by you and your project, but is a consideration that must be made as you analyze and define how you will build a solution.
It is important to keep in mind that we should use these patterns as they make sense for the project and the organization, not just for the sake of using patterns. In addition, we are not looking to automate each and every pattern that we may come across – we need to be pragmatic and practical in regards to the automations that we build. Some of the questions that we refer to for guidance when thinking about pattern implementations include:
- Is the pattern automatable?
- How can we simplify how patterns are consumed?
- How can we speed up and simplify how patterns are created?
Here are some considerations to help in determining if a pattern is a good candidate for automation:
Pattern computability: Is the information in the associated pattern specification precise enough so you can codify it into a pattern implementation? Would it be too complex to automate? Would the input model be too complex? Is the pattern specification too abstract to allow you to derive an automation? Are the possible pattern variants clearly mapped to a set of variability points (aspects provided to the user to adapt the pattern to his specific situation)?
Tooling availability: Do you have tooling available to automate the pattern? A pattern implementation cannot be created if the tooling or technology to automate the pattern is not available. For example, we would not create a pattern implementation if the development environment or the language we use make it more difficult to develop the pattern implementation than to develop the solution following specifications.
Reusability: Does the pattern implementation offer sufficient ROI? Whether we look to reuse the pattern many times, or just a few critical high value times, the cost of developing the implementation needs to be covered – otherwise we should stick to just a pattern specification.
In case such as the ones listed above, we will be better served by using a pattern specification.