Design Patterns - Introduction.

Sunday, September 13, 2009

Computer Science is relatively a very new stream when compared to Civil Engineering or Mechanical Engineering etc,. Moreover, Computer Science is very difficult to quantify. How do you quantify a Software program? On what basis would you say that a software is successful or failure?

In other matured branches, people have tried many different things, documented their failures, done root cause analysis and documented their results as well. But, Computer Science being a very new stream, people have the liberty to use it in different ways on their own. On top of everything, the products of Computer Science are very difficult to quantify and thus making it very difficult for people to communicate as well as document anything. I've read an article about the success rate of software written till date and it says, the success rate of software engineering is only 11% based on their computation criteria. Their criteria is a very long list including the re-usability of the software components, proper abstraction, enough room for future changes, extensibility, scalability, etc,.

So, as we see, Software Engineering or Computer Science as such has got only a 11% success rate. Now, we have the big question before us. Why is it so? We can list out so many reasons. But, one reason that stands out tall is this - Computer Science was never considered as engineering and we never tried to quantify the work as in other engineering streams.

People, all over the world, work in software designing and do solve problems on daily basis but the wisdom never got spread across. Every one of them thought they are the only people who face those problems. They never thought that there might be some one in the other part of the globe trying to solve the very problem they are facing now, because people never thought that building software applications are exactly similar to building dams or constructing sky scrapers or designing complex circuitry.

It never occurred to them that they might be trying to find a solution for a pattern, a problem that surfaced again and again. People, designing software, spent precious time in rediscovering the solution for a pattern again and again.

Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution, in such a way that you can use this solution a million times over, without ever doing it the same way twice".

Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.

Four people, who are called as The Gang of Four, Erich, Richard, Ralph, and John present a compelling case for the importance of patterns in crafting computing systems. They recorded the experience in designing object-oriented software as design patterns. Each design pattern systematically names, explains and evaluates an important and recurring design in object-oriented systems. Design patterns make it easier to reuse successful designs and architectures.

With their book the Gang of Four have made a valuable contribution to software engineering. We've got a lot to learn from them and apply them in all our work in-order develop a really good software.

0 comments: to “ Design Patterns - Introduction. so far...