33

I've heard it argued that design patterns are the best thing since sliced bread. I've also heard it argued that design patterns tend to exacerbate "Second System Syndrome," that they are massively overused, and that they make their users think they're better designers than they really are.

I tend to fall closer to the former camp, but recently I've been seeing designs where nearly every single interaction is replaced with an observer relationship, and everything's a singleton.

So, considering the benefits and problems, are design patterns generally good or bad, and why?

Improve this question

11 Answers 11

Reset to default
55

Design patterns are a language, not advice to write program or a contract. Their primary use is an a posteriori explanation how a component or a system was (or is going to be) implemented. Instead of going into too much details, you can just say a couple of words that can describe the implementation well enough for the listener to understand how it works and what was important in it.

Alex: Hey, how are the config files created?

Bob: They're generated by a factory, which resides in config.h.

Now Alex knows that creation of config files involves non-trivial preparations, because otherwise their creation wouldn't be enclosed into a factory.

However, if Bob was a pattern-headed phony, and just used patterns here and there, Alex couldn't tell anything about config creation, because Bob used factory just everywhere. This would also lead to excessive complexity in the program.

So, program first, then spot patterns in your code, not vice versa. That's how they're effectively used.

Improve this answer
4
  • 11
    +1 anyway, but especially for "then spot patterns" - that's precisely how we got patterns in the first place, but looking for recurring problems.
    – Frank Shearar
    Oct 4, 2010 at 6:11
  • 16
    They're called design patterns for a reason. While there's nothing wrong with spotting patterns as you're coding, there's nothing wrong with identifying appropriate patterns before the coding begins. The problems lies in acting like a hammer and thinking everything is a nail.
    – George Marian
    Oct 4, 2010 at 7:38
  • 11
    The important thing is to spot the patterns in how the code will work, instead of saying "which Design Pattern should I use for this code", which too easily leads to bureaucratic code bloat. Especially when you mis-use DPs aimed at one language in one with a different coding methodology.
    – Peter Boughton
    Oct 7, 2010 at 17:20
  • Nice answer. My definition of adoption: any technique is considered to be adopted only after it is identified as executable, compilable artifact in build chain. No amount of books, blogs and hardbreathing handwaving worth a single real instruction in a build chain.
    – user7071
    Jul 22, 2011 at 22:22
14

Design patterns are great. When used properly they make code more maintainable, easier to read and work with. Part of being a good programmer is knowing when to stop and see that any further refactoring will outweigh benefits. Using design patterns alone doesn't make somebody a good programmer, but knowing when and where to use them does. Just like with anything else in this world design patterns can be taken to extreme and be abused. I know I'm still looking (and will be for a long time) for that perfect balance in my code where every design pattern has a purpose and falls into place perfectly just like a piece of jigsaw puzzle.

Improve this answer
10

Design patterns are great, if used correctly.

It's useful to remember that the idea of design patterns originated in architecture. Architecture can vary wildly. However, there are many core ideas that are present in any building. In this way, think of patterns as building blocks of design. It is important to note that not every building includes all possible architectural patterns.

Say you're designing a house. Rather than having the front door open onto the street, you want a sheltered area before entering the house, i.e. an anteroom. This area will fit a certain pattern. Namely, it will have two entrances, some walls and probably a roof. Note, the pattern does not specify doors, windows or how many walls. In most implementations, there will be two doors, four walls and maybe windows. However, the pattern describes an enclosed area with two entrances. One leads into the anteroom itself from outside of the house and the other leads into the rest of the house. The key here, is that if you want an anteroom you must enclose an area and provide two entrances into that area.

The typical problems with design patterns in programming are over use and the belief that they are silver bullets to fix any issue. They are not. They are ways to communicate and think about useful programming ideas. If the bits of syntax of a particular language are the bricks and mortar, patterns describe useful ways to arrange them to meet a certain needs.

Improve this answer
1
  • +1 great explanation, especially noting that they are best used when designing the system. Unfortunately, the knowledge about where and how to use those patterns mostly come from the experience of refactoring previous systems, where they were spotted only during implementation. So my version is a minor extension: think first, then write code. Then analyze the result, refactor if required and possible. Next time more patterns will be obvious before coding :-)
    – Lorand Kedves
    Jul 6, 2012 at 11:03
7

I consider design patters more of "advice" than an unchangable contract that absolutely must be followed. Why? Precisely for the reason you mentioned. Following a design pattern in everything leads to a big mess of code that defeats the purpose of using a pattern in the first place.

This is why I hate sites like Java Practices. Sure some of the idea's are good, but then the author decided to write an entire program (plus a framework) following every single design pattern he mentioned. The author also wrote every article with big scary quotes making the reader think that actual java practices are horrible and should be avoided like the plague.

TL;DR: Use design patters. Just don't abuse them

Improve this answer
1
  • I've generally been somewhere between skeptical and cynical about design patterns. I don't think I've directly had occasion to want to use them in my professional work. Possibly this is because I don't use Java or "hardcore" OO C++. Interestingly. Richard Gabriel reports that the originator of design patterns (Alexander in building architecture) had some nasty failures in actually applying design patterns to buildings and didn't seem to actually ever attain the quality of buildings that Alexander was looking for with design patterns.
    – Paul Nathan
    Oct 15, 2010 at 16:22
2

Also seet this thread on SO. From another POV design patterns are boilerplate code to compensate for the shortcomings of the used methodology. I am not a fan of celebrating those workarounds too much.

Improve this answer
6
  • ANd yet instead of using the languages that make those patterns less necessary (Common Lisp and Smalltalk leap to mind), people continue using languages that require said boilerplate.
    – Frank Shearar
    Oct 16, 2010 at 12:07
  • My thoughts exactly.
    – missingfaktor
    Oct 17, 2010 at 8:47
  • 1
    Design patterns should never be thought of as boilerplate. Boilerplate is defined as "sections of code that have to be included in many places with little or no alteration". On the other hand, design patterns are not just chunks of code. They are broad principles about how to structure code to solve certain types of design problems. They do not have a specific implementation. Implementation of design patterns should always be varied according to the needs of a project.
    – Kramii
    Jul 23, 2011 at 7:19
  • @Kramii: For example a "Function Object"/"Functor" in imperative programming languages is boilerplate code compared to functional languages, where functions are first class. You do not have to code anything there, it's supported in the language. Vice versa you have to use a "Design pattern" called "IO Monad" in Haskell to get sequential, imperative I/O, which you get for free in imperative languages. I recommend following the thread i've linked to.
    – LennyProgrammers
    Jul 25, 2011 at 7:06
  • 1
    @Lenny222: I've read the link and agree with your point that patterns overcome shortcomings of a language. However, I disagree with your use of the term "boilerplate". Boilerplate typically refers to repeated implementation of the same code - often the equivalent to copy-paste code or at least templated code fragments. OTOH the implementation of design patterns should be implemented in different ways according to requirements.
    – Kramii
    Jul 26, 2011 at 19:47
0

I will prefer those in the middle. Like the poster rightly pointed out, an understanding of patterns does not make you a good developer. On the other hand an understanding of pattern will help you become a good developer.

Understanding the relationship of patterns and seeing a pattern in a project (while at the conception stage) is what will make you a good developer.

Improve this answer
0

It's often said that design patterns provide a ready-made solution for programming problems. What kind of problems are they? "How can I change object behavior, but isolate the changes from the rest of the system?"

The GoF patterns are recognized for providing that isolation (encapsulation) from the rest of the system, but it's often difficult to know what part of the system is given variability through the use of their design patterns. Instead of following the classification scheme they proposed (creational, behavioral and structural), I charted the patterns' differences and came up with two other schemes to classify their patterns: lifecycle and component encapsulation hierarchy.

design pattern encapsulation hierarchy

As you can see from this table for the encapsulation hierarchy, design patterns can be applied at every level of a component. But would it make sense? Will the component need to provide behavioral variation at the encapsulation level proposed, and is the proper pattern used for that level? If these questions aren't properly answered then design patterns are most likely misapplied. Just because a vertical pivot could be built into the cabin of a car doesn't make it a smart idea.

Improve this answer
0

Using an analogy to money, a design pattern should be thought of as a solution with high capital cost but low operating costs. Design patterns cost a fortune upfront in terms of extra coding, verboseness and the conceptual weight from the extra indirection they create. They also have a tendency to lock down other aspects of your design. For example, using template method forces you to program in a heavily OO style.

However, if you need to solve a lot of closely related problems that vary in some small ways, or are definitely going to need to modify a piece of code heavily in some specific ways in the future, the upfront costs can be worth it because design patterns add flexibility to your code. The modifications or the solution to the second of your set of closely related problems will be a lot easier with patterns than without.

Improve this answer
0

Both camps are correct - they're a force for good when used correctly, a force for bad if they're splattered all over the place.

Improve this answer
0

Design patterns can have a knack of drawing you in, but the same is true of coding in general. It's easy to get seduced by writing the ultimate tool box - you've just got to keep YAGNI in mind to stop you getting drawn off course, get a feel for how much structure the application needs. IMO this is just down to the individual and a mark of their experience/judgment.

Improve this answer
0

I think of design datterns not of something that you're constantly trying to apply to your code. For me it is mainly about a common language for developers. It's easier to say "we follow a builder pattern" than explaining the whole thing over and over.

I'm currently re-reading Patterns Of Enterprise Application Architecture right now, because I stumble upon a lot of code that follows one of the patterns from that book. I don't think it was intentionally chosen to follow one of the patterns, but it definitely helps if you can say "it's a transaction script" and everyone has a clear understanding what that means.

But I like the idea that you can choose from a prepared catalog of patterns, when you design a new functionality or a brand new application. Why reinvent everything if there are proven solutions for certain problems?

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.