Pages

Friday, January 16, 2009

An interesting PALM vision

http://www.palm.com/us/products/phones/pre/palm-pre-ces.html

Thursday, January 15, 2009

Too much overloading, OOPs

Here is a scenario I encounter often; right, people think they are writing a good Object Oriented programming if it has different methods that are overloaded. The idea is that, others can consume one or the other method based on their need, by writing such overloaded methods I give you more flexibility. And by doing so, this becomes a good OOP. Guess what, essentially all they are doing is adding more complexity and clutter in code.

As every statement needs a justification, let's see the scenario:

I have a protocol that takes n parameters, in order for a consumer to run his test case he would need to set up some parameters as an initial condition.
say there are 3 parameters for simplicity, a, b, c.

public settings Initialize();
public settings Initialize(a,b);
public settings Initialize(b,c);
public settings Initialize(a,c);
...

In a real world obviously the parameters could grow in size. So what happens when a 4th parameter is added say d. You have to write overloaded methods encompassing the different combinations. so it becomes 3 X 4 times for example, this magnitude could grow. There could be justification that there is enough methods that use the different initialize and hence it is not required for each case to set the value it wants(code replication), but when the software grows it adds more problem.

The better way to go is, have a method with no parameters and have another one that takes an object which is composed of all the parameters.

create a class and put all the settings parameter in one.

public class AllSettings
{

Public layer A
{
get{return a;};

set{this.a = value;}
}

public network B
{
//
}

public InitialSettings
{
get
{
if(A == Null)
{
A = defaultValue;
}
//so with B and C

return settings; //Has all the initial settings required.
}
}
}

By doing the above, you get to choose if you want to initialize part of the object or not by using the set properties. And a final check is done for NULL, before the actual initial settings are created. If it is null put some default value, if not fine.

So in this case if a new parameter pops up later in development, it is as good as adding a new property and setting the default value. Existing cases need not worry about that and the new ones can override the default with the set in the property.

I have heard this comment too, do i have to create a class for this? Is it not costly? Well we have evolved now in the managed world where you do not worry about the object creation and deletion. Also some debate on the style cop issues, where you have to create only one class per file, this is debatable but since it is a different topic; I will leave it aside for now.

For better design in .NET, please refer to Framework Design Guidelines (useful links below). The design guidelines states the above scenario in a different way. Though the design guidelines book states the above scenario to be handled in a different way, the change I have indicated is an acceptable and agreeable design style!

URLs:
PDC talk by authors.
The link to the book.

Note: All the code examples are based on C# programming language.

Tuesday, January 06, 2009

Test driven development in short.

This a post to express my understanding of test driven development.

Say you are a dev and you are given a clean slate and a spec, what do you do?
The first thing people do is to write the design code per the spec. Instead if you start writing the test cases and then start your dev code full filling each test case it becomes test driven development. The process is iterative, once few test cases are full filled, you go back and refactor the dev code to make it better. The process of continous refining, while full filling more test cases on each run is termed as test driven development.

This method is a best fit for developing API's. In a test driven development you as the dev becomes the first consumer. So if you do not like it, there is a very little chance that some one would.

Friday, January 02, 2009

New year!

A new year is often embraced for new hopes and a new beginning. Yes, every year indeed brings in the much awaited cheer to all. The year 2008 was good in some aspects, bad in some aspects, turned out to be a positive year for some, horrible one for others and so on.

But everyone on the planet wakes up with new hopes on the Jan 1st of every year, to embrace the next year. Is this all real? I mean what's in an other day (the next day) that changes you from yesterday?

Come on this is human after all. We talk about a broken economy, terrorism in the dusk of the yesteryear. But suddenly wait for things to change in the new year, yet what is happening is all by ourselves. Are we wanting some alien to change things for us?

This phenomenon is very human if not truly human. It is our calendar days that point out; earth has turned a year older for better.

It is amazing to think what as a species we have done to ourselves. We have created our own pleasures and pains. Say for example, Let's think whose fault is this economy? what if there was no economy? Is it good or bad?

Anyways with these thoughts in mind, let's think that every day would bring in new hopes and cheers to us.

Leaving this post with a final quote, "Everything on this planet is almost human and yet it is not!"