Tag: Design pattern

Architecture Patterns and Design Patterns

Architecture Pattern – It expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Examples : Architectural framewoks like Zachman, ( ZIFA ) provide the user with a pattern for the designing the enterprise. The OpenGroup also discusses more on this.

This article details the various attributes of a system, and where does software architecture fit it.

Design Pattern – It provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.

Examples : Adapter, Fascade, Singleton, Proxy to name a few.The book on Design Patterns by GOF, provides an exahustive list of design patterns. The Hillside site also has various patterns. With the dynamic change in software its becoming increasingly large to create new patterns, like the one Yahoo has. The TRIZ journal entry also correlates how to use design patterns along with software engineering.

Idiom – It is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

Example : Idioms generally relate to a particular programming language. Curiously Recurring Template Pattern is considered an idiom in C++.

Other interesting articles on Idioms can be found below:
a) Idioms and Patterns in Architectural Literature.
b) C++ Idioms – Coplien .
c) C++ Idioms .
d) More C++ Idioms .

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.

Design patterns, Antipatterns and Refactoring – Useful Site

Today I found a good site on design patterns, anti patterns and refactoring.

Has some good stuff … need to check it out more.

Related articles