Thursday, May 10, 2007

Software design goals and philosophies….

“Every extra week spent in making a good design will always be paid off “

What is a good design?

There are no definite metrics to judge a software design to determine the degree of how good it is.
Though there are ways to see if they stick to some common guidelines and methodologies.

1.Define problem from the software consumer perspective – Say for example there is another developer who will use your design/code, end user or for that matter any one.
2.Does the proposal address the problem statement
3.RED flag design issues, these are not necessarily mandatory, but definitely we must pay attention to.
a. Near neighbor dependencies
b. Wise use of asynchronous design
i.Essentially not to block requests.
ii.In all possible ways this design should be implemented.
iii.But there is overhead in writing code.
4.Use of Has-A VS Is-A
•Inherit - Use same method implementation, this should be the type chosen only it makes a strong sense to use it, which means better to go for the aggregation model.
•Aggregate – Encapsulate lots of smaller classes.
•It also makes sense to make such an encapsulated class public so that others can use the same.
5.Develop more generalized code and it is better to have more dumb classes, when combined together makes a smart. The best example would be the .NET framework which is built over humongous amount of small classes, which makes the libraries much richer.
6.Make sure the transactions happening through different objects are framed correctly. If any circular pattern is found in the transaction model, then it is not a good design.
7.Make sure that there is no dependency on each layer.
8.Each transaction between the objects should contain parameters less than or equal to five to make it more simple and understanding.
9.C# vs. C++ code testing: There is not a different approach/angle of testing the C# code from C++.

1 comment:

@VELU said...

welcome back !!