#class-oriented

A few month from now, I really thought I knew what Object-Oriented programming was. Not only did I learn it from eminent professor at school, but I also practiced it, learnt all the design patterns from the GoF book and talking about java-style interfaces and abstract class was one of my favorite topic.

I've been diving recently into the core of Ruby and Smalltalk, not just the syntax or the object-model, but also the philosophy behind it. What's striking is that the core concepts - or way to conceive your programs - is radically different in Smalltalk and Java.

At first, I thought the difference came mostly from dynamic typing versus static typing. So I tried to bring the two worlds together with a project called umlify that generates UML diagrams from ruby source code. This just goes to show that to me, OOP was merely a static classification and description of classes, and UML was the perfect, understandable blueprint of it.

It took me time to accept that the difference wasn't limited to static or dynamic typing. It was hard for me to accept it, but my conception of OOP was completely false. What I was doing was Class-Oriented programming.

This article is more of a work-in-progress. I'm trying to clarify the distinction between the two seemingly related paradigm first for me, and it will certainly not be comprehensive nor always right. Just take the information and read this with a critical eye.

Differences between Object-Oriented and Class-Oriented Programming

COP: We think in term of classes

OOP: We think about objects

Consequences of Class-Oriented

We tend to categorize. We care about class hierarchy. Inheritance becomes a common pattern.

Categorization leads to abstract classes. They seem very useful to add more classes in a category in the future

Not only do we categorize classes, we also categorize different method under the same name, through method-overloading.

Polymorphism can only be achieved through inheritance.

Problem

Classes are static

At run-time, the program is dynamic.

"Object-Oriented program's run-time structure bears little resemblance to its static code structure" - GoF 

Classes in a hierarchy tree are tightly coupled.

A simple modification in a class hierarchy can produce unexpected ripple-effect

Method overloading: We can't think about all the possible use of a method at run time when programming in the large.

A coupled source code isn't chunkable.

 Impossible to do a proper peer-review without understanding all the dependencies.

Conclusions

Class-Oriented works well in a "closed-universe" (i.e. programming in the small), but fails in the wild.

We only address half of the problem with class-orientation.

COP tend to make program more complicated and less reusable.

I think Class-Oriented programming is easier to define than Object-Oriented. If you're wondering what is OOP, bear in mind that people are still arguing today over the proper definition. From all the research I've done, it seems like everybody has it's own idea on the question.

Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind. - Alan Kay

Too bad Alan Kay didn't tell us what he had in mind!

Sometimes it's good to go back to the basics. One thing we deal daily with are objects. We all know what they are, we manipulate them, we pass them around. They are really cool, they answer our questions, perform some stuff for us, and once we don't need them anymore, we just leave them there and don't bother calling them anymore, and since the world is a cruel place, they even get collected by that garbage collector guy...

But what really are objects, beyond that conceptual entity? Why does an object respond to method calls? How can it know it's own state? Why do we talk about "object-oriented" in some cases, and about "class-oriented" in some other? What's a meta-object? How about a meta-class? Oh boy so many questions!

Since I've found so many great resources online, I'm mainly going to refer to these.

If you want to know what is object-oriented programming, I would suggest to start by reading that great resource explaining the Smalltalk Object Model. Smalltalk has one of the purest implementation of object-oriented programming to date. Ruby is directly inspired from Smalltalk, and you'll be surprised to see how they look alike.

From there, it's said that:

An object is an encapsulated software component made up of memory and operations that creates a coherent programming entity. All objects are an instance of a class. Everything in Smalltalk is an object-from numbers to entire applications. Objects have public and private properties. An object's implementation details are private and are hidden from other objects. An object's public properties are its messages that make up its interface. The object's private properties are its variables. Interaction with an object only occurs via these messages to its interface. All object instancesof a given class have a common message interface.

The Ruby Object Model is a recording from Dave Thomas' talk about Objects in Ruby.

So what's an object?

It's an entity with a state (instance variable) and behaviors (methods). This concept is the same no matter what OO programing language you are dealing with. An object is always something that is composed of methods and data. It is an instance of a class.

What's a class?

In a pure object-oriented language, a class is an object. It is an instance of a class. The class that defines a class is called a meta-class. A class defines the behavior and state of the objects it represents. In Ruby, I like to see a class as a factory that has a method to create new objects. Since a class creates other objects, it is called a meta-object.

What is a method call?

In pure object-oriented languages, there are no such things as lonely methods. They are all bound to an object. This is the case in Ruby, all methods belong to an object, not to a class. A class is a placeholder for the methods its objects implement. Each objects of a class share the same methods, however, and this is a crucial point: each method of an object is bound to one, and only one instance.

duck.quack

Here we're calling duck's quack method. If you feel wordy, you could also say that you call the quack method defined by the 'Duck' class on the duck instance.

One step further: what's a meta-object protocol?

It is an API build in the language to allow manipulating its object model. I just talked about method call, and with a MOP, it is possible re-define that. One could also redefine other concepts such as inheritance (and maybe take it off!).

Not every language offer a MOP API, but they all define an implicit MOP. It's simply how the language handles object-oriented under the hood. Ruby doesn't implement a MOP API. With a MOP, we could for example implement Aspect-Oriented paradigm into our language. More: Does Ruby have a Metaobject protocol and if not, is it possible to implement one?

How about metaclasses?

In Ruby just like anywhere else, it's only a class that defines a class. However, Ruby defines another concept that doesn't officially have a name but that people refer to as eigenclass or singleton class. A singleton class is an anonymous class that defines a single instance (thus the name).

For more on the subject I recommend reading Why's Seeing Metaclasses clearly.

So what's the difference between Object-Oriented and Class-Oriented?

The best answer I've seen so far comes from this link. The idea is that in class-oriented languages, you need to use inheritance to use polymorphism or to artificially represent related objects. The difference is also closely related to the difference between the dynamically typed and statically typed world.

Other great sources of information: