Recognising Design Patterns
- 3 minsSince I started my journey with 8th Light, I’ve been immersed in best practises and part of those practises, is learning and understanding design patterns; knowing how to spot them, when to use them and when not.
In my last blog post I wrote about the Command Pattern and even though I get the general concept of it, it’s still not evident how to spot it and when to use it. An example I came across which caused some confusion is something we use in one of our projects, a filtering queue.
To demonstrate an example, I shall use the ever so useful Marvel Universe:
The intent of the Command Pattern is to: “Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations”. The ElementFilter
and TypeFilter
are in this instance the command objects. The HeroeFinder
acts as the client and takes a “queue” in the form of the filters
. I could of put an instance variable with an array inside of it so that it would be more clear but I opted for removing the state instead and pass the queue directly in the filter
method.
According to the definition above, this piece of code still conforms to the Command Pattern. However patterns like Chain of Responsibility add a level of confusion to the untrained eye (me). Despite the fact that clear differences exist, they can be tricky to see, especially if they’re mixed with others. More training and practise is needed indeed.