Levels of programming, based on design principles.

Just a small writeup based on the programming design style, that I commonly come across with various programmers.
To give some context, let's take an example of creating an object called car (automobile).

Level 0 programmers are those who think, writing more common code is better and generalize them in to static methods that take numerous parameters.

public static void CreateACar(Engine engine, Color color)
{
//rest of the code here;
};

The problem is if the car needs to be created with a new property like sedan/coupe, then a new parameter needs to be added and this keeps growing. If the arguments grow then they add a structure to encompass all these arguments and pass them.

The next level of programmers are those who treat each of attribute of the object as it's property and create a class like the below:

class Car : IAuto
{
private Color color;
private Engine engine;

public Engine Engine
{
get
{
return this.engine;
}
set
{
this.engine = value;
}
}


Public IAuto CreateACar()
{
//rest of the code;
}
}

The above code works great, even if there are new parameters to be added. It is as simple as adding new properties and verifying them before creating the car. But some assumptions have to be made, say this car runs on a "road" and the car creation assumes the road to be some type (could be Enum) and ties the object to it. What if the road's condition changes and a car that code run while creation cannot run all the time on the road. Some cases/scenarios while creating the car is missing and it does not cover all the situations. This is what happens when the object is strongly tied and has lot of properties.

The next level of programmers are for making functionalities atomic with individual classes and then tying them together based on the scenarios or rules. The rules defines what goes in creating the car object.

say it could be class Road, class Car, Interface IAuto etc.

Looks like more classes that has smaller functionality. Yes, exactly these are all small dumb classes and are atomic. But when combined with the rules and scenarios that change time and again, they come in handy as they are very flexible and requires less change.

Take the .NET library, it exactly fits the last design model discussed, more dumb classes combined together giving a great flexibility and power for creating more applications.

This is a followup of my initial design post - http://globalhandler.blogspot.com/2007/05/software-design-goals-and-philosophies.html