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

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.