?

Log in

October 21st, 2006

Are Objects dumb nouns?

Never before in my life I had seeing such a great misunderstanding about some sort of thinking, the thinking of design computer software based on intelligent objects, behavior plus state, bound, for better human understanding and maintainability. That's the story of a very good humored rant on Object Oriented paradigm that started gently as just a unimportant, misplaced critic on the Java syntax. (Warning: great amount of sarcasm and irony below)

This unforgivable sin of Java not allowing you write functions without a class as its context (yes, this reading requires some basic OO principles, I'm not sorry) was WAY OVERHATED by the author of Execution in the Kingdom of Nouns (referred from now on simply as the rant), in such a way that it takes about 1,500 of words (small games could be written with that) to make its critic. To those of eager to know why I was so perplex in front of this, let me give you just a example:

in C declaring a function would take you some code like this:
int inc(int i) {
    return i + 1;
}
In Python:
def inc(i):
    return i + 1
In Ruby:
def inc(i)
    return i + 1
end
In the grotesque Java the following nature's mistake would have to be written:
class foo {
    static int inc(int i) {
        return i + 1;
    }
}

More verbose, indeed, 2 astonishing lines of overhead, can you imagine? Two lines per source code file!!! Indeed, we cannot bare such errors in science. </br> But let's keep going on with our example, let's for a moment image a Java source code file with about 3 or 4 functions:

class foo {
    static int inc(int i) {
        return i + 1;      
    }
    static String logError(String s) {
        //code here
    }
    static void order(int[] a) {
        //code here
    }
    static double buy(int productId) {
        //code here
    }
}

With this examples in hand dear reader, you can make your own judgment of who has a case of Xenophobia.
As you can see, we keep with the unacceptable 2 lines of code overhead. I think I'm done with this part of the rant, which by itself could never call my attention in such a way to the point I loose precious hours of my weekend to give my tiny share of justice to the facts I'll present.

The fact that the Object Oriented design of software is a natural evolution of the procedural way of thinking.

But let's first retain ourselves to the statements in the rant.

because architecture consists entirely of nouns. (from the rant)

Architecture in OO software design if not about nouns or data, but it is about behavior, operation, verbs! That's the base of OO, the aspect called polymorphism. Never heard of it? Oks, let's evolve, have you ever used or saw a powerful feature of C called function pointers? Oks, evolve that idea a little more, add to your language a natural syntax for that and you will have the very first bricks to what was named Object Oriented design. But of course, that's only part of the story.

Have you ever heard or used global variables? Oks, have you never wanted them to have a less global scope? have you ever wandered where this variable was declared? In which file? Have you ever imagined why some company had the idea to put the types of each variable in its very own identifier (perhaps because it was too painful to find its declaration...). And finally but not less important, have you ever prefixed a group of variables or functions with the same name? like:

In terms of functions (verbs):
logError(String msg); 
logWarn(String msg); 
logTrace(String msg);
In terms of data (nouns):
String clientName;
String clientAge;                           
String clientEmail;
double clientDeposit;
Perhaps Both?
scheduleVacation(Employee e, int month);
String EmployeeName;
double EmployeeSalary;

Can't you see this functions and variables are naturally trying to live together? And the great majority of us humans can't make sure the salary of one Employee won't be used to process a client deposit? In real life systems that today easily have hundreds of thousands of lines of code, wouldn't it be better if a compiler of interpreter stop us from mixing all these global variables in our huge data bank of programming code statements?

To bind data and functions, state and behavior, nouns and verbs is what OO calls objects. It can be class based as Java or Prototyped based as Javascript, it does not matter. BTW, the author of the rant puts Javascript as regular procudural language, couldn't this definition be more wrong. In JS every function is a object.

Let the compiler or the interpreter (or mainstream IDEs, more common among statically typed languages) handle the consistency between data and actions. Of course, no software today can prevent you from mixing your data or make a bad design, but I think I just don't need to explain the problems of global variables among thousands of lines of code.

Objects narrows down the scope of global variables to a single instance. I'm not talking about having the scope of a source code file, I'm talking about the scope of a instance, your functions will act only upon a logic gathered set of data (and of course the parameters of your functions [I'll stop with the obvious, I promise...]).

In java you can have:
class foo {
    static DatabaseConnectin conn  = ...;
    static int currentQuarter = ...;
    
    static int inc(int i) {
        return i + 1;
    }
    static String logError(String s) {
        //code here
    }
    static void order(int[] a) {
        //code here
    }
    static double buy(int productId) {
        //code here
    }
}

The marked lines above are not a C regular global variables, but package global variables, which restricts their scope a lot less than the hole set of files of your application.

But wait! You can also have single file global variables (each time less global huh?):

class foo {
    private static DatabaseConnectin conn  = ...;
    private static int currentQuarter = ...;                                         
    
    ... functions here ...
}

The marked lines above makes these variables available only to the functions of one source code file. Reducing drastically the number of implicit dependencies among all other functions in all other files and these variables. Memorize this concept called "Implicit Dependencies", ask yourself why they must be avoided?
Any experienced programmer will know the answer. And certainly OO techniques helps us to avoid them.

Have you ever found yourself coding like this:
setLifePoints(&player, points);
moveToRoom(&player, roomId);
initNPCs(&room, npcs);

Well, that's just objects Player and Room screaming to have their own voice, their own right to shout verbs, their own functions, to handle their own data.
After all, in the most cases all we care about is the actions of our code to be completed, not how they are performed. Let us create this concept of Objects and let them handle themselves with their data, let us just ask them to take the garbage out for us, close the garage door, enter the house, etc (the rant references).

Well, Object Oriented languages have just a natural way to express this, this wau is the creation of no one less than the very own hated and feared... Objects!!! (doesn't "hate" have its origins in fear?).
A very different way of thinking software design, in such way different that some people just feel really insecure to dive into. But that's all normal, to loose a paradigm is to loose, for at least a short time, the floor underneath your feet.

class Player {
    setLifePoints(int points) { ... };
    moveToRoom(int roomId) { ... };
    moveTo(Room r) { ... };
}

class Room {
    initNPCs(npcs) { ... };
}

It's far beyond the scope of this blog entry to teach the Objected Oriented design techniques, as it's also the teaching of Good OO principles. We must remember, ANY tool can be badly used, never underestimate one man's imagination :)

Dude, not everything is an object. (from the rant)

I agree that other paradigms like the Functional one has its safe place under the sun, as OO has also its safe place under real life BIG systems, what I cannot say about the procedural approach, because even being possible, there are better ways like OO. Designing intelligent, behavior targeted objects is not easy as simply design procedures but on the other hand is not like learning Hebrew, not at all.

And let's make something very clear, the Functional paradigm is a world apart from procedural and OO ways of thinking (the rant rightly states that).

I did not want to get back to that syntax huuuge problem of Java, but one final note about it, with java 5 static imports the rant author can have almost all he wants from java syntax. Badly designed libraries exists in all realms of computer languages, the syntax of how to declare or invoke functions could never be held responsible for that, isn't it obvious?

Getting back to what matters most, the true value of Object Oriented systems comes from Polymorphism, when behavior morphs or change from a type implementation to another, and switch cases are banned from cloning themselves all over the system, along with data boolean expression to take specific actions.

I'll dare to try to give some examples, (even without presenting important mechanisms like inheritance, interfaces, etc):

You could have a Type Employee and two implementations of this type, the Director and the Manager. The type would define common operations like calculateBonus, scheduleVacation and approve(Project). Each type implementation or Class would implement these operations according to what it would be representing, a simple Manager or a mighty Director. You would only have to ask each type instance to calculateBonus, scheduleVacation or approve(someProject) without needing to know the rules specific to each type implementation. No switches every time to check if(employee.type == MANAGER) { ... some project workflow approval ... }, so when a new project workflow approval appears you do not need to chase or grep hundreds of files to add one more case statement.

Well, examples much more decent, elaborated and supported with code are available in the literature since a few decades now. I do not intent to try to teach (which is a art by itself) the little I know about OO here.

Even though I just hope to have helped to undo this huge misunderstanding of such good software modeling technique without whom great projects like Eclipse or the Spring framework could not be done, among hundreds of others even more expressive (give me a break, I can't and don't want to remember much more, it 00:44 am, Friday ;) Ask KDE developers what they think about OO if these java world examples are not appealing.

I strongly recommend the reading of Object-Oriented Modeling and Design. And also a lighter reading on chapter 7 of Objects First with Java.

This is a very passionated post, I know I could be more didactic and clear, but I just want to end this wrinting for this weekend :)

Latest Month

July 2016
S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      

Tags

Powered by LiveJournal.com
Designed by Tiffany Chow