How important are Design Patterns really? [closed]

Answer 1

Design patterns are taught in design classes for CS. They aren't essential, but really helpful if you can find analogous situations to have a solution that has been thought through.

It also allows programmers to communicate more easily. You can talk to your coworker in terms of the patterns as well. If you say here I have my Observer, then it is pretty well understood what is kind of going on.

People will naturally come up with solutions that will fit into a design pattern on their own, but the design patterns help to define terminology and standard ideas that can be helpful.

There's nothing super remarkable about the patterns, the nicest thing is that they are ideas that are canonized and defined in ways that are repeatedly useful.

Answer 2

I find design patterns of marginal value. Any well-organized and designed software framework has hundreds of design patterns, and very few of them are described in the formal "pattern literature".

Before there were design patterns, there was well-designed software which had many patterns that could be re-used in many situations. For example, Kernighan and Ritchie's book on C contained an example of a calculator implemented using yacc and lex and a stack, symbol table, function pointer passing (i.e. basically dynamic binding) and contained a large number of patterns for the size of the book.

You can probably learn hundreds of more useful design patterns by studying e.g. Microsoft's .NET framework, Java class libraries, etc. than by reading a book on design patterns.

Really, good software has a design. And if the design is good, it can probably be re-used. Voila -- a design pattern.

Answer 3

They are not absolutely needed, but the good definitely outweighs the bad.

The good:

1. Code readability: They do help you write more understandable code with better names for what you are trying to accomplish.
   • Code maintainability: Allows your code to be maintained easier because it is more understandable.
   • Communication: They help you communicate design goals amongst programmers.
   • Intention: They show the intent of your code instantly to someone learning the code.
   • Code re-use: They help you identify common solutions to common problems.
   • Less code: They allow you to write less code because more of your code can derive common functionality from common base classes.
   • Tested and sound solutions: Most of the design patterns are tested, proven and sound.

---

The bad:

1. Extra levels of indirection: They provide an extra level of indirection and hence make the code a little more complex.
   • Knowing when to use them: They are often abused and used in cases that they should not be. A simple task may not need the extra work of being solved using a design pattern.
   • Different interpretations: People sometimes have slightly different interpretations of design patterns. Example MVC as seen by django vs. MVC as seen by Ruby on Rails.
   • Singleton: Need I say more?

Answer 4

Start with Principles before considering Patterns, because it's the overarching design principles that inform and motivate the emergence of patterns.

For your particular problem you are best served by following principles first and foremost. If you arrive at a well-known Pattern then, congratulations, you just re-discovered a Pattern, good for you. The problem is that it could take you a long time so it depends if you want to risk inventing a few anti-patterns along the way or whether you want a short-cut to something that's already been published. Consider it though, because you'll learn more than reading someone else's description of their own work.

The down-side (as many of the very good answers here have already pointed out) is that you could be tempted to apply a published Pattern in a context where it doesn't fit or just is not warranted.

A good place to start with Design Principles is by looking at Uncle Bob Martin's SOLID principles, the nice thing about them, once they sink in, is that you feel like you already knew them (which makes you feel smart) and

Uncle Bob's book Clean Code also covers alot of the same principles with some useful examples, only not so explicitly citing the principles as the original articles, focussing more on generally organising and tidying up your Functions, Classes, etc.

Answer 5

We used design patterns in the 80's, we just didn't know they were design patterns.

Answer 6

Important isn't the word that I would use. I would use the word "helpful". Giving developers a common language to describe frequent problems/solutions is useful -- moreso in a collaborative environment.