How do you know when to use design patterns? [closed]

Answer 1

If you know the patterns, then they become tools in your toolbox. When you look at a task, you select from your tools. At that point you should have a pretty good idea which tool is the best fit for a given problem. This is where formulas stop working and you actually do engineering work.

Answer 2

I would highly recommend reading Head First Design Patterns from O'Reilly. This explains how these patterns can be used in the real world.

I'd also add that don't try design too much with patterns in mind. More, look for "code smells" which a pattern might help solve.

Answer 3

I agree that just learning the patterns is not enough. The problem with most books is that they do not provide real-world examples. I've heard that Head First Design Patterns, as some suggested earlier, is a good one.

Another thing is that most books are intentionally not language-specific, which may be both a good or a bad thing for you. However important is to understand a pattern in general, it is equally important to know how to implement it well. I've come across a book called C# 3.0 Design Patterns which devotes just about equal ink to both of these unseparable aspects.

Answer 4

A design pattern is a generic description on how to solve a common problem. There're 2 things we should pay attention to:

First, it is a Generic description; it's not the concrete solution, and it's not a complete recipe either, it's just a description on how the solution would look like in order to approach a common problem.

Second, the problem is question is a common problem:, that means this problem has been encountered many times before, and over time people developed a description for how an ideal solution can be applied to this commonly repeated problem.

So, if you're encountering a new problem that's not common, try not to use design patterns to solve it, or at least don't make design patterns your tool to just solve any kind of problem you face.

Answer 5

Design patterns are supposed to provide a structure in which problems can be solved. When solving a real problem, you have to consider many tiny variations of a solution to that problem to see whether any fits a design pattern. In particular, you will probably need to generalise your problem, or its solution, in order to make a design pattern fit.

The answer is, it's an art. Knowing the design patterns is certainly an important step. One way to get used to this sort of thing is to study applications of design patterns, not just the patterns. Seeing many different applications of one pattern can help you over time to get better at mapping a task onto a pattern.

Answer 6

The concept of a design pattern has been taken from structural engineering, as with many practices in software engineering. If you consider building a structure, there are decisions that need to be made on how to build that structure to achieve the goals set out. When making those decisions, you will have a set of requirements to work from. It may be something as simple as Bridge must be able to support X tons at one time, or have a particular tensile strength to allow enough movement in wind etc. An architect would use prior knowledge of other builds to make those design choices. He/She would be very unlikely to try to solve the problem from scratch.

Software Engineering and Design Patterns are exactly the same. They are simply common solutions to common problems. If you know the design patterns, then when you are working through a design, and particular part of a system requires something that fits a design pattern you have, then use it. Don't try to fit a system round a design pattern, fit design patterns in to your system (where they fit). Just try to think of them as a set of solutions to reduce the amount of design work you need to do, and be cautious of over-engineering your solutions to cram in as many design patterns as you can. This will just serve to make your solution unmaintainable and probably quite buggy.