Pattern spotting

So, I mentioned previously that I will be time boxing my learning. It has been a couple of weeks since I have been giving myself half an hour to research a pattern and then presenting it to the rest of the team during team lunch on Fridays.

So far so good!

I have covered few patterns, but on this occasion I would like to have a more general discussion about process of using patterns and what I think the pattern is.

Did you know that patterns fall into categories? It is interesting how not everyone who uses patterns regularly is fully aware about their categorisation.

Having been on a pattern discovery for not very long, I want to know under which circumstances I should be using one pattern or another. My hunch is that knowing the categories can help in narrowing down which pattern to apply when you need one.

There’s a slight problem with that thinking… I remember an experienced programmer told me once that you don’t search for a pattern you should use, but rather you start seeing them… What does that even mean?

What he was trying to say is that the process sort of flows in a different direction, you get to a point when you start noticing common problems/limitations and you start applying a similar technique to those. In your solution to the problem may even be using a common pattern without you knowing you have done it.

I find that in the early days of your journey as a software engineer, whenever you come across a definition of what the pattern is, it seems very obscure, at least it seemed so to me, the definition doesn’t really give you sense of understanding unless you have experienced the process I described above. Here’s the most common definition of a design pattern:

Design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

It is not difficult to imagine that you and Gang of Four shared problems in common, we work within the same domains and with the same limitations. But why is it not uncommon for developer to come up with a similar solution on his own as what Gang of Four outlined in their book?

The reason why this is possible is because you are pursuing the same goal and are trying to follow the same design rules.

If you are using patterns that is because you care about good design and because you are trying to follow SOLID principles. Therefore, while steering your code in that direction it is likely that you will often discover pattern all on your own.

This is one thing I realised, to be ready to be using pattens you need to have principles of good design in your sight. So before discovering those, discover SOLID principles for yourself.

All patterns have their trade offs. Sometimes you can use one or another in your particular situation and you have to evaluate which is the most suitable. To fully appreciate the subtle differences, when looking at patterns, what you really want to look at, are real code examples.

Most of the time you get UML diagrams and conceptually it may makes sense, however to actually start seeing the problem through the code and being able to apply is another step.

Well, this is my general take on patterns so far, and in one of the following posts I would still like to go through different categories that patterns fall into.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.