Object Oriented Rules of Thumb

Beware: This are rules of thumb. The methods criticized by the rules are a good solution in some contexts. This rules shall not be carved in stone.

Rule 1: The 3 to 5 steps rule

If you can convert your Object Oriented solution to a Structured Solution in 3 to 5 steps you are not doing as much object orientation as you think.

Example 1 A System of Managers.

This is your typical “object-oriented” system composed of lots of singletons with names like “Manager” that manage collections of objects that are no more than glorified structs with lots of getters and setters and just a couple of silly methods.

This solution is obviously a smell. But for some reason, due to the usage of the singleton design pattern it has become an occurring and somewhat approved approach. “Come on, I’m using design patterns, how do you dare to say the design its wrong! Come on! God-Class???”

Steps to reveal the truth hidden in the design:

Step 1. Put your manager class and its managed classes in a single file.
Step 2. Convert the managed classes to structs.
Step 3. Convert the managed classes methods to module methods (as static methods in C)
Step 4. Put the manager state as module state (as module data in C)
Step 5. Convert your manager methods to plain old functions. Put them a prefix if you want to emphasize module cohesion.

And that’s it. You object oriented solution is now what it was in reality: a plain C module with some exported functions and local state.

Example 2: An action-oriented system

This is also your typical “object-oriented” system composed of lots of classes with verb-like names that are created, executed and destroyed. This pitfall is common in people that come from an structured background (I know this has been stated to death and is nothing new) but is also common in people whose first exposure to object-orientation were toolkits that model their actions as objects (which is OK if you are modeling an action, but terribly wrong if you are modeling your domain objects).

Steps to reveal the truth hidden in the design (this is easy):

1-Convert your object to a plain function
2-Convert the object data to a struct.
3-Fill the struct
4-Invoke the function passing the struct as a parameter.

Some would say: “but your function could get really large, if I do it in an object I can partition it into lots of private methods”.
I say: “Dividing a long function to make it easier to understand is just dividing a function to make it easier to understand, it is not object orientation!”


Hello world!

int main(){

std::wcout << L”Hello, World…Press” << std::endl;

return 0;


November 2018
« Jan