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
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!

PDC talk by authors.
The link to the book.

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


@VELU said...
This comment has been removed by the author.
@VELU said...

so true, this one of the core phil of C++.

Earlier in procedural code one has to have zillions of globals and there would to be fns usually taking like < 6 params - while with c++ one could easily pack them into class and magically the member fns need not take the members variable as arguments.

Global Handler said...

At least with c++ you have to deal with the object creation, deletion blah blah...
The traditional prog. is carried out from the past in to C#, your managed world as well...

anyways will be blogging next on Jeffery Richter's try catch principle vs other patterns!