I just had to post this here. How people have such wrong ideas...
The reply is not much elaborated because I did not think at first in showing it here.

From a Ruby discussion group:

On Sep 27, 7:29 pm, MenTaLguY <men...@rydia.net> wrote:

    > On Fri, 28 Sep 2007 06:31:47 +0900, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
    > > Most of the GOF book deals with the issues raised by statically
    > > typed oo languages, and aren't as portable as one might think.
    

My reply:

You couldn't be more wrong, being statically typed does not interfere in the runtime messages exchange between your objects.

Design Pattern or better saying Object Oriented Modeling is just about how to better model the communication of your objects in order to get more reusable and maintainable code.

Those OO techniques are highly valid for Java, C++, Ruby or Python world.

More thoughts of mine about Object Oriented Design here.

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 :)

For those trying to get into the world of Object Oriented modeling I strongly recommend the reading of the seventh chapter Designing Classes of the book Objects First with Java, indicated by my coworker Maria Cristina.

in chapter 7, we discuss more formally the issues of dividing a problem domain into classes for implementation. we introduce issues of designing classes well, including concepts such as responsibility-driven design, coupling, cohesion, and refactoring. an interactive, text-based, adventure game (world of zuul) is used for this discussion. we go through several iterations of improving the internal class structure of the game and extending its functionality, and end with a long list of proposals for extensions that may be done as student projects.

Even if you are experienced software developer and face the problem of justifing the use of OO principles to your coworkers this chapter and its examples are a good source of inspiration and arguments. I must say that it uses a simple Text RPG Game to show good modeling of maintainable code, nevertheless those are techniques that will improve your real life systems.

I strongly recommend this reading for OO beginners and evangelists.

From Miguel de Icaza's blog entry about Lang.NET Symposium:

Compiling Ruby is challenging for a number of reasons, the lack of a language specification means that sometimes the only specification for the behavior is the source code and because Ruby has a lot of features that do not map easily into the single-hierarchy, multiple-interface object model that is part of .NET. So Ruby.NET has to generate a number of helper classes and runtime support to provide the expected behavior.

It's sad to hear that Ruby has not yet a formal specification.



That reminds me a study made by a now Google engineer with 18 languages targeted at the JVM. There are script languages, some with functional features (like closures), others with class based Object Oriented paradigm, others like Javascript with a prototyped OO approach and even one Lisp like.

A friend of mine recently asked me what criteria do I use to decide over choosing a abstract class or a interface. Other criterion than the possible obvious need of some operation implementation (a.k.a. method) for which one must choose the abstract class I would say that the main optic through which I see interfaces is to represent Roles a particular object can play.

Let's try one example:

The Application:
We have some application architecture that defines a environment for its components (or plug ins) to make operations on rendered images. So we can have plug ins that makes several types of operations like zoom, pane, add other images as layers, selection, etc.

The interaction between different class instances:
Some plug ins might depend on receiving events from the others like, a plug in has been activated or deactivated, has refreshed the screen, has opened a pop up menu, etc.

A possible problem:
A common mistake would be to hard wire the concrete type of this different plug ins make each one listen or fire the events pointed above.

For example:
Make the plug in 'A' having a association to plug in 'B' to fire to it the 'refreshed screen' event. That would enhance the coupling and reduce drastically the re usability and maintainability of your classes (the plug ins in this case). You could not deploy another set of plug in to some different Client that uses only the plug in 'A' or 'B', because now one references the other and they are now tied forever.

Think of that in the real world where you could have the order of 10 different plug ins, would you like to have only the possibility to move then in block? Or would you like to change some code in one of then and not be sure of the behavioral changes propagated to the others? Think, the simple association of their concrete classes opens all the public operations of one to the other, every change in one of this operations should consider all its clients (as clients I refer to objects that have access to it). Is there a need of exposing all the public operations of one plug in to the others just to fire or listen one specific event?

A Solution:
Make one plug in see each other through specific Role interfaces, no big deal here, just following what graphical toolkit designers have done for years. Interfaces that aggregate the minimum set of operations to represent a specific Role. One interface just to listen the 'image entity selected' event and other just to register the listeners. That way your plug ins, their concrete classes, act responding to specific roles that any other concrete class might respond to. Their interaction is sustained not anymore by their concrete classes exposing a lot of unnecessary public methods, but they are bound to only the operations they need, reducing coupling, augmenting reuse and providing a better life to the human maintainers of these classes :)

---

That's a real base principle in Object Oriented modeling techniques, so I'm aware this might not be great news to many experienced developers, but maybe a interesting tip to new ones ;)

As to Abstract Classes they are only one way the express a constraint in some classes, this constraint is 'cannot represent by itself a full implementation of the contracts its operations define' so extend it, implement the full set of operations, specially the ones missing, those declared as abstract, and now make use of it.

I was wandering in a used books shop when I found a little bookshelf of Computer Science books. One book written in brazilian portuguese came to my attention with a title that could be translated to 'Modeling and Object Based Design'.

I´ve started reading the back-cover, and it said the authors were sugesting a new process and notation of object oriented software design, the first thing strange, I never heard of brazilian authors in this matter.

I´ve look some pages and saw a very familiar graphical notation, more specific James Rumbaugh notation, and thought ' This is not new, just a copy o J.Rumbaugh notation'.
Looking what was clearly a class diagram I thought again: 'This is no copy o J.Rumbaugh notation, this IS his notation', second thing strange.
I´ve saw tips of how implement OO design in non OO languages as also OO languages like C++ and Smalltalk (which made me think again).

I´ve finally went to the table of contents and saw very interesting subjects and wandered who in the end were its authors? And to my surprise in the cover I found the name James Rumbaugh among others, hehehe.

Went to see the original title and it was the good old 'Object Oriented Modeling and Design', that shameful until now I didn´t started reading. Well, I had to buy the book (as it was used it was really cheap) and this is finally changing now :)

Booch again:

Everything is a problem of classification.
Indeed, there are two kinds of people in this world: people who divide the world into two classes, and those who do not.