Is Something Wrong With OOP?

Object orientation has been in the limelight since forever. We have all kinds of Object-Oriented things like programming languages, development methods, diagramming techniques, and database systems. Well, I’m not going to talk about everything but rather, I want to discuss if OOP is being taken completely wrong. Don’t hate me just yet for this dramatic statement (I have nothing against OOP) but stick with me as I explain what I mean.

A few questions!

Talking about Object-Oriented Programming, languages, like C++ and Smalltalk, both are object-oriented but there’s a world of difference between the two. Considering the difference that exists between OO languages, it raises a few questions like:

Objectiveness

Objectiveness defines the extent to which things are objects. In small talk, everything is an object and all functions are methods of an object. In C++, you have ordinary functions and integer values.

The class construction model

Does the language have inheritance, multiple inheritances, interfaces, polymorphism, and so on? Visual Basic is called an OO language and it does not even have real inheritance. Java does not support multiple inheritances. Are classes defined statically or dynamically? Are classes first-class objects?

The object construction model

How are objects instantiated? How are they destroyed? Do you have to do it yourself, or is it done automatically? Does the runtime environment do garbage collections?

The type system

Is there strict typing? Is it possible to invoke a method without knowing the exact class of the method? Is there a reflection?

The object life cycle model

How about object persistence? Can an object be transferred between computing entities? What about external references to object?

It makes me wonder if there is any general idea or a consistent theory about what an OOP is. Something is certainly fishy here.

Does language actually MATTER?

Are all the above mentioned just language problems or is there something else going on? Let’s start from the beginning. What exactly OOP is? Let’s ask the father of OOP; Alan Kay,

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.”

So as far as I’ve understood, OOP is -

Messaging
Local retention
Protection and hiding of state-process
Extreme late binding

But are we missing something? Where are classes?? What about Objects???

Let me refer you back to Alan,

“……..it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"….The key to making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.”

So what’s the concept behind OOP?

The strongest concept of OOP is messaging; the idea of how objects communicate with each other. Basically, there are two layers to OOP,

Declarative Layer: Where we create and compose the objects
Application Layer: Where the objects communicate

And classes??? Well, classes are the declarative layer of the declarative layer. By that, I mean classes are “factories” for the objects. They define the blueprint for the object. You can have as many factories for objects as you want. Objects and Classes are a part of one of the layers of OOP. OOP virtually treats everything like an object whereas classes are just a way to create them (not to forget there are other ways too).

Let’s take another look at OOP,

On the very basic level, OOP is a methodology to create a modular design that is easily modified without having to restructure the entire system. It is meant to keep software projects manageable for programmers. How?

Modularization - by decomposing the problems into sub-problems (problem is broken down into smaller problems) that can be solved individually and independently.

Abstraction - by representing complex real-world in the simplest manner and providing understandability

Encapsulation - by hiding the internal, complex details from the outside world. By protecting low-level functionality

Composability - by allowing structured design. By allowing modules to be combined freely in order to produce new systems

Hierarchy - by allowing the incremental development (bottom-up approach: developing complex modules from small and simple component modules)

Continuity - by allowing change and maintenance in just a few modules without affecting the overall architecture.

So OOP is about the implementation of above-mentioned features and not about the way we implement them. The methodology changes focus from system to object. At the system level, it asks for separation of concern and high level of abstraction when the objects demands for encapsulation, low coupling, high cohesion and context independence. Let me clarify it more with an example. Consider the following code snippet in JavaScript.

var box = {
type: “square”,
color: “brown”,
getInfo: function() {
return this.type + ‘box is’ + this.color;
}
};
box.color = “yellow”;
alert(box.getInfo());

No use of classes in the above code but is it not object oriented? One thing to be mentioned here is that JavaScript is not an OOP language neither it has classes but it does support OO style of writing code. After all it is OOP and not COP.

Let me summarize...

Now, let me answer the question I asked in the title. No, there’s nothing wrong with OOP; rather with how we began to define it. The reason I brought this question up is I happened to come across some posts pinpointing the problems with OOP but taking a closer look it seemed that confusion rose due to misunderstanding the piece for the whole. OOP is a style; a methodology of programming just like procedural programming is a style of programming and offers its own benefits.

I recently wrote about Functional Programming in C++ (not to mention C++ is considered OOP language) and I might write the above Object Oriented Programming in JavaScript or Python (both are not OOP languages). The only point I’m trying to make here is that languages are getting support for all styles of writing code for the reason that both styles are the demand of the day. It’s up to us to choose which we are more comfortable with. But to learn the right way is surely important.