What should come first -- the design pattern or the code?

Question

I'm starting on a fresh new project--should I look at my spec and decide which design patterns to apply, or just come up with a general idea of organization and allow the patterns to emerge organically through refactoring?

In your experience, which technique will be most productive and have a greater chance of leading to clean elegant code?

I'm also wondering if there are design patterns out there that aren't defined by the GoF, but could be just as valuable? If so, what are some useful resources for informing myself about these?

Answer 1

You should grow your code organically, applying patterns as they fit. Matching up with patterns too early can lead to a lot of inappropriate code and so many layers of abstraction that the design becomes obfuscated. Witness any code you've seen that was written right after someone had discovered patterns for the first time ;-)

Answer 2

1. Figure out use cases.
2. Think of design looking throughout the existing design pattern.
3. Start to implement.

I believe the main goal here is to avoid reinventing the wheel.

PS. After you'll pass step 2 for several time and get used to it, you will be able to integrate that step into step 3.

Answer 3

Unless a pattern seems to obviously jump out of the spec, I wouldn't necessarily try to pick something from GoF and hammer the problem until it fits the pattern.

It's better to conceptually understand the different levels of abstraction in your head and come up with a plan (not necessarily a popular design pattern) for how you will implement it. This is something you will get better at with experience. While knowing the GoF patterns will help you improve your ability to think about problems in terms of code design, they are not meant to be solutions to every problem, and artificially forcing your problem to fit into a design pattern can mean unnecessary complication and obfuscation.

Answer 4

You should have a grasp of which patterns would fit the problem before you start coding. If not, make a prototype so you understand the what you want to achieve. Then look for patterns and throw away (the structure of) the prototype (and reuse the good bits).

Answer 5

If I'm ever unsure I just start writing code. Before too long, the structure will start to beg for some refactoring and the choice is nearly always obvious.

Although I am sometimes inspired by a particular pattern, it's almost always the code that shows me the right path.

I'm also not afraid to burn down and rebuild parts of a program. There's a quote I like a lot from Scott Adams - "Creativity is allowing yourself to make mistakes; art is knowing which ones to keep." Sometimes the right answer isn't obvious until you try it the wrong way.

Answer 6

Good advice in here already. To answer the question about useful patterns other than the GoF book. There are, you should check out Larman's Applying UML and Patterns where he describes GRASP patterns.

Answer 7

I'd stay away of patterning your coding too much by upfront design pattern usage. It is better to just make simple code and when needed refactor towards a design pattern that then captures your requirements best.

Answer 8

You should grow your code organically, applying patterns as they fit.

Seconded! Some of the worst spaghetti I've seen is OO C++ with lots of patterns. Fluxbox is barely bearable; Synergy (v2) boil, broils and bakes my noodle :(

And some of the most beautiful code I've seen is OO C, where the OO was two interfaces plus 4 and 20 implementations, respectively.