Learning JavaScript Design Patterns

Chapter 3. “Pattern”-ity Testing, Proto-Patterns, and the Rule of Three

Remember that not every algorithm, best practice, or solution represents what might be considered a complete pattern. There may be a few key ingredients here that are missing, and the pattern community is generally wary of something claiming to be one unless it has been heavily vetted. Even if something is presented to us that appears to meet the criteria for a pattern, it should not be considered one until it has undergone suitable periods of scrutiny and testing by others.

Looking back upon the work by Alexander once more, he claims that a pattern should be both a process and a “thing.” This definition is obtuse on purpose, as he follows by saying that the process should create the “thing.” This is a reason why patterns generally focus on addressing a visually identifiable structure—i.e., we should be able to visually depict the structure that results from the pattern in practice.

In studying design patterns, it’s not irregular to come across the term “proto-pattern”: a pattern that has not yet been known to pass the “pattern”-ity tests. Proto-patterns may result from the work of someone who has established a particular solution that is worthy of sharing with the community, but has not yet been vetted heavily due to its very young age.

Alternatively, the individual(s) sharing the pattern may not have the time or interest of going through the “pattern”-ity process and might release a short description of their proto-pattern instead. Brief descriptions or snippets of this type of pattern are known as patlets.

The work involved in fully documenting a qualified pattern can be quite daunting. Looking back at some of the earliest work in the field of design patterns, a pattern may be considered “good” if it does the following:

• Solves a particular problem. Patterns are not supposed to just capture principles or strategies. They need to capture solutions. This is one of the most essential ingredients for a good pattern.

• Does not have an obvious solution. We can find that problem-solving techniques often attempt to derive from well-known first principles. The best design patterns usually provide solutions to problems indirectly; this is considered a necessary approach for the most challenging problems related to design.

• Describes a proven concept. Design patterns require proof that they function as described, and without this proof, the design cannot be seriously considered. If a pattern is highly speculative in nature, only the brave may attempt to use it.

• Describes a relationship. In some cases, it may appear that a pattern describes a type of module. Although an implementation may appear this way, the official description of the pattern must describe much deeper system structures and mechanisms that explain its relationship to code.

We would be forgiven for thinking that a proto-pattern that fails to meet guidelines isn’t worth learning from; however, this is far from the truth. Many proto-patterns are actually quite good. I’m not saying that all proto-patterns are worth looking at, but there are quite a few useful ones in the wild that could assist us with future projects. Use your best judgment with the above list in mind, and you’ll be fine in your selection process.

One of additional requirement for a pattern to be valid is that it display some recurring phenomenon. This is often something that can be qualified in at least three key areas, referred to as the rule of three. To show recurrence using this rule, one must demonstrate:

Fitness of purpose

How is the pattern considered successful?

Usefulness

Why is the pattern considered successful?

Applicability

Is the design worthy of being a pattern because it has wider applicability? If so, this needs to be explained.