When to use which pattern? [closed]

Question

As a junior developper, i'm a bit confused about some design patterns. Sometimes, i just don't know which to use in which context.

For exemple, on creational patterns, i don't really know when to use:

• Factory
• Prototype
• Builder

Actually, i see some differences; but i also see that you can use multiple solutions like:

• Calling a factory that calls the appropriate builder that clones a prototype.
• Calling a factory that clones the appropriate prototype
• Calling a builder with the appropriate director
• ...

I mean, the result of these creations is at the end the same: you get your object instance.

I just wonder what kind of design you would use on different contexts (i guess it could be depending on performence needs, objects complexity, coupling...)

Also, I don't really see a big differences between a facade and a mediator, except the mediator calls different interfaces.

Same for chain of responsability, don't really understand why all implementations i see use chained lists. Can't this pattern be implemented with a simple List of handlers that we call successively?

That's why i'd like people to tell me in which concrete context you would use a GoF pattern, and also why you wouldn't use any of the other patterns that could have fit to the given problem (but probably in a less elegant way).

Thanks

Answer 1

Like many people when I first came across design patterns I realized that a lot of them were simply names for mechanisms I'd already used to solve design problems. The problem came first, then the solution. I never approached design patterns like they were puzzle pieces that needed to fit somewhere.

You're not really required to answer a problem with the name of a pattern as if it was an exam. The way to do it is to sit down and think about what you need your code to do and how it may change in the future. This is how we got to these design patterns anyway. People kept using the same tricks to solve a certain set of problems until eventually someone came along and gave those tricks names.

The only problem you have is lack of experience and that can't be fixed just by SO. As you write software you'll invariably get some things wrong. You'll discover that if you had done things this way, they would have been better. Incidentally this way has a name; "abstract factory", "adapter", "observer", whatever. In the future you'll know when and why to use it. For now remember the KISS principle. Don't complicate things that don't have to be complicated.

The fact that you're aware of design patterns before knowing how to use them means that you're a step ahead of most devs. Don't sweat it too much, just remember that next time you have a problem one of them might be an acceptable answer. Little by little you'll find out when a design pattern should be used and when it shouldn't.

Answer 2

What I want to stress the most in this answer, is my disagreement with this bit of another answer:

It's difficult (as you've noticed) to apply a pattern for the first time and understand what the benefits might be

You have to see a clear benefit the pattern will give before applying it. If that's not the case, don't use it, adding patterns to your code that don't give clear benefits will very likely fall in an anti-pattern scenario.

That's why i'd like people to tell me in which CONCRETE context you would use a GoF pattern, and also why you wouldn't use any of the other patterns that could have fit to the given problem (but probably in a less elegant way).

First, don't limit yourself to what you read there. The best aspects of the patterns is to enable you to acquire design options to several different scenarios.

Naturally there are scenarios that can be done in more than one way. Struggling choosing between 2 patterns in a very specific scenario? check them again, see what they said about the scenario and the benefits.

If you find yourself overwhelmed with the amount of patterns, give most of them a rest. Don't introduce all the patterns into your skills at once. Pick a related handful of those, and learn well when to apply them (read them again, search/ask for comparisons in SO/blog posts.

Always pay attention of how good the patterns you have applied respond to changes and how its the complexity of the code around them. Ask yourself the question on how those characteristics would be different with any of the other alternative patterns.

Finally, understand that you are best following an evolving code approach. Do your best in keeping your code clean, but don't obsess on finding a solution that won't ever have to change. Even with the patterns at hand, you will be taking some assumptions, that can impact which pattern you chose. Changes might not be in line with those assumptions, is a fact or life.

Read these 2 ebooks, can help you greatly on focusing how you design/develop/improve code.