Design Patterns: Do you use them in your projects?

Question

How do you decide on which design pattern to choose for?

My approach to development projects has always been.

1. Take down business requirement.
2. Design the database.
3. Decide on technology (This decision is almost always driven by the client.)
4. Start developing a prototype.
5. Get prototype approved. (iterative)
6. Build the application.
7. Release for testing. (iterative)
8. Hand over for maintenance.

I am not sure where a design pattern would be useful.

Answer 1

Step 6 (build the application) would be a good bet. Although I understand Neil's comment about deciding design patterns during the design phase (which you don't really have), I find they often emerge during construction, as you're coding/refactoring. Of course, it helps to know in advance what the design patterns are, and it's difficult to know them without using them, so it's bit of a vicious circle.

Answer 2

Usually before you build the prototype and always before you build the application you have to design it. Here is where a knowledge of design patterns come very handy since not only helps you with the design but also when communicating your ideas with other developers. For example when you tell another developer that a particular class is a Factory or another is implemented as a Singelton they immediately have a better grasp of what and/or how they do what they do and how they fit with the rest of the application.

I very much would recommend "Head First Design Patterns" from O'Reilly to get you started.

Answer 3

It will be useful in the 4th and the 6th step... :-)

In prototyping design patterns can be really handy. If the existing architecture/design isn't flexible enough, then adding more features to an existing prototype will be really messy. Though it doesn't mean that you should always use design patterns. It's the principle they teach is important, like open-close principles, information hiding and how to do that properly and when, favoring composition over inheritance etc. All these guidelines have been there to make the job of adding more features to an existing application/prototype less painful.

Over the course of your development career, you will see such principles to be used in many places. It isn't necessary to strictly follow some patterns, but the principles behind those patterns that you should try to follow.

Hope that helps.

Answer 4

Use of design patterns is inherent in any development. You list it or not, a lot of implementations do follow design patterns. Knowledge of design patterns surely help designing an application which is robust, scalable, easy for maintenance and of-course easy for understanding. There are also a lot of cases where use of design pattern helps optimizing your solution. In a typical software development cycle like the one you mentioned, use of design pattern is extremely crucial in prototyping phase.

As an example, lets suppose you need to implement a communication layer which supports communication using different protocols (XML/Http, WebServices etc). In prototyping, you can easily implement a layer and make your application communicate using the layer directly. If you would use Factory pattern and a simple implementation of any one of the protocols in prototyping then extending the final application becomes a piece of cake. This not only saves the overall development time but also ensures a cleaner approach for development.