Design patterns are required to have in your toolbox. While there are plenty of them - it is useful to classify them. When you have a problem - you have to come up with a decision using your toolbox. If there is chaos in your toolbox - you have less chance to find a right pattern. In the metaphor the toolbox is your brain, obviously. Keeping your knowledge organized helps us to cope with large amount of information. Taking a simple example from programming - we have words condition and loop. When we try to solve a problem or discuss it with someone else - we rarely say concrete constructions (at least we don’t mean it). You might quickly recognize that to implement an algorithm you need a condition with a loop inside. You still don’t know and don’t want to know what exact language constructions will be used. You have to stay on high level of abstraction until you solve the problem and then make step forward (even down) to implementation.

We have the same situation here. Before thinking about loops and conditions we have to define the design. The same rules applied here - we have to stay on a high level before choosing concrete design patterns to adopt (if any). What we really have to think about is what kind of flexibility is required. From domain rules you can derive required level of flexibility. If you know about meta patterns - you can easily choose the right option supporting required level of flexibility. Afterwards, we make another step and use existing patterns under the meta pattern or invent new tricks with the same template and hook scheme.

Let’s have an example. We are given requirements to implement a feature to display all hotel rooms in Antalya, Turkey available for booking per provider. Each provider has its own API that can return any requested information. We need to understand what flexibility do we need in this case to build a design solution supporting the required flexibility. We detect a common part (template) - hotel rooms finder. Then we detect changing part (hook) - provider. While we have one provider used by finder at each request - we have T&H 1:N connection. Since there is no is-a relation between our finder and external provider - we need Non-Recursive connection. Having decided on this high level detail and on many other things (e.g. we will need some kind of factory) that are excluded for simplicity, we can make the next step. We would first have a look at design patterns supporting this kind of flexibility. As we will see later - we have Strategy under this category that fits us the most. Stop. We missed so good options - there are so nice patterns available for this exact case - Factory method and Template method. Or did we? We are sure (in this example) that we don’t want inheritance relation here. That’s how we were able to define what kind of relation do we need filtering patterns not even thinking about them. If we go other way around - we would have to choose patterns that help us to do the job providing varied method or object. We would not even be able to filter them with existing categories while template method and Strategy are in Behavioural group and Factory method is in Creational one.

Image

Fine, I hope now you see the reason to learn meta patterns. Organizing your toolbox leads to more efficient use of it. I don’t say that it is a required knowledge for every developer - it is more like an optimization for professional developers. A Where() filter before a big loop. Now let’s go back to the article.