Why should you use design patterns

Every time when we are working on a software , we come across problems, think about it and then implement the solution .

Design patterns are very effective in this context as it provides us with a tested solution; we just need to work around it .

A simple example would be a database application – which also has a GUI front end .

Normal Approach

1) Create a class which shall encapsulate the database table ( e.g a RecordSet class )
2) Use the recordset class object to tie up the data with your GUI
3) Test the application and deliver it to the client .

You have done an excellent job – the application is up and running and the client is much happy as much you are.

Situation after three years ( the tool has become very popular )

1) The client needs to increase the number of columns in the existing table ; he might need some more .
2) He gets back to you, and you tell him that it can very well be done.
3) Remember the earlier recordset class wont work here as the contents of the table has changed.
4) You create a new recordset class, tied up with the new table/s and become successful again.

The client again praises you for the newly done job, and you get a fat hike .

Revisiting the application using patterns

You could have used the adapter pattern ; and the code would had been much neater .

By using this pattern, you would have written some extra code, but it would have been beneficial in the long run .

Instead of a single recordset class, you could have had three classes – provider, broker, consumer. The responsibilites of each class are discussed below .

Provider class would have connected to the database table
Broker class would have done the intermediated job of handling the tables, stored procedures.
Consumer class would have fetched the contents from the broker and displayed in the UI .

So if the table changes at any point of time, you can modify the above classes accordingly and make yourself and your client more happy.