When to call the gang of four? [When to use design patterns?]

Question

In The Guerilla Guide to Interviewing Joel says that guys who want to get things done, but are not smart will do stupid things like using a visitor design pattern where a simple array would be sufficient.

I find it hard to detect, if the design pattern suggested by the Gang of Four should be applied.

Therefore, I would like some examples from Your work experience

• When is a simple approach (fixed size array) sufficient?
• What is the minimum size of a piece of software that justifies the use of the GoF patterns?
• When to refactor from simple-minded to GoF? Can this be done in a sensible way?

Answer 1

This is similar to any other design decision. Ultimately, it depends. You should learn those patterns that are useful in your language (many GoF patterns aren't needed in Lisp or Smalltalk, for example), learn their advantages and disadvantages, understand the constraints of your system, and make the choice that best fits your needs.

The best advice that I can give is to learn, learn, learn.

Answer 2

I often find that using test driven development helps guide me when faced with these questions.

• When is a simple approach sufficient? It is always sufficient to use the simplest approach to get the next test to pass. But knowing when/how to refactor is the real art form.
• What is the minimum size of a piece of software that justifies the use of the GoF patterns? A rule of thumb I once read is that when you code something once, fine, when you duplicate that code somewhere a second time, make a note and move on. When you find a need for the same code a third time, it's time to refactor to remove duplication and simplify, and often that involves moving to a design pattern.
• When to refactor from simple-minded to GoF? I like what @anopres said - it's time when you feel the pain of not having the design pattern in place. The pain (or code "smell") may manifest itself in several ways. Code duplication is the most obvious. Refactoring books like Fowler's Refactoring or Kerievsky's Refactoring to Patterns list many such pain points/code stenches.
• Can this [refactoring] be done in a sensible way? The trick to refactoring is to have a suite of unit tests in place which you have confidence in, and then to refactor without causing any of those tests to fail. Refactoring, by definition, does not change the functionality of your code. Therefore, if your tests continue to pass, you can have a pretty good feeling that you didn't break anything. Although it can be difficult, I actually enjoy this part of TDD, it's almost like a game to make changes without breaking any tests.

In summary, I would say that TDD helps guide me to write the code that is sufficient at the time, and perhaps more importantly helps me to make the changes later when inevitably requirements change, more functionality is required, etc.

Answer 3

Switching from a simple approach to a formal design pattern is usually something that happens fairly naturally for me as a problem increases in complexity. The key is to be familiar enough with the patterns that you can recognize the tipping point and switch from the simple approach to a design pattern when it will bring the most benefit for current and future development.

For a larger, more complex project, the tipping point should be fairly early on; in many cases, before you even start coding. For smaller projects, you can afford to wait before deciding to implement a pattern.

One of the best things you can do to increase your ability to recognize when a pattern should be used is to take some time after completing a project to examine how complex your "simple" approach has become. If it would have taken you less time and effort to implement a pattern, or if the pattern would clarify what you were trying to do, you can file that knowledge away for the next time you encounter a similar problem.

Answer 4

Design Patterns are a consequence, not an objective. You don't think today I shall use Strategy Patterns, you just do it. Halfway through doing the third nearly identical class you stop and use a paper notebook to figure out the general case and knock up a base class that describes the shared context. You refactor the first two classes to be descendants, and this gives you a reality check and quite a few changes to your base class. Then the next thirty are a walk in the park.

It's only the next day at the team meeting that you save everyone thirty minutes of boredom by saying "I used strategy pattern. They all work the same so there's only one test program, it takes parameters to change the test case."

Intimate familiarity with patterns makes you use them reflexively, whenever the situation demands it. When people treat the use of patterns as an objective in its own right, you get stilted, ugly code that speaks of mechanism rather than purpose; the how rather than the why.

Answer 5

When you have a problem that one of the patterns solves. The GoF book has a section in each chapter that explains what types of scenarios each pattern is appropriate for. You should not analyze each problem you have, then go look up what pattern to use. You should become familiar with the patterns so that you learn to recognize what situations call for them.

Answer 6

Patterns are only tools and vocabulary. You write the code to be as simple, understandable and maintainable as you know how. By knowing patterns you have more allternatives at your disposal, and you have a language to discuss pros and cons of the approach before implementing it.

In either case you dont just "switch" to "using a pattern". You just keep doing what you allways do, write the code the best way you know how.

Answer 7

One of the nice things about the the original GoF book is that there is discussion of the scenarios where the pattern would best solve problem. Reviewing these discussions can help you determine if "it's time".

Another good place to start is with Head First Design Patterns. The exercises that illustrate the use of different design patterns are elaborate enough to offer a good learning experience. In addition the exercises are also grounded in real world scenarios, so it's never a stretch to see when the appropriate times to apply design patterns.