Programming Paradigms: Object Oriented vs Data Oriented

Over the last couple of decades, different programming paradigms have emerged in an attempt to make software better. Different situations demand different requirements, so it wouldn’t be fair to say that one paradigm is better than the other. Whenever you want to create a software system, you usually write code that attempts to fulfill most of the requirements. Now the difference between these paradigms is the way in which you write your code. On one end of the spectrum, we have object oriented programming. The world revolves around pieces of data here and functionalities are attached to them. On the other end of the spectrum, we have data oriented programming. In this paradigm, everything is just data. How does that work? What exactly is this spectrum and how do we understand it?  

What is object oriented programming?

You must have heard people talking about OOP right? OOP stands for Object Oriented Programming and it is a programming model that has gained immense popularity in the last couple of decades. It is practically a gospel in some parts of the programming world today. Basically, OOP’s main focus is on attaching functionality to particular pieces of data. For example, if you have a bunch of specifications about a car, you might want to group that together and attach some car-specific functionality to it. The functionality can be, let’s say, the car’s ability to go from 0 to 100 mph quickly or how the car’s mileage varies between city streets and highways.

Different pieces of data can represent different kinds of things, so it makes sense to couple functionality with “type”. C++, Java, Ruby, etc are a good examples of object-oriented languages. If you consider Java or Ruby, everything is an “Object”, and things are instances of particular “Classes” (which are Objects themselves). Every object here has a particular set of operations that you can perform on it, and it usually contains some kind of data. Encapsulation, Polymorphism, and other nice things arise out of the object-oriented paradigm.

What is data oriented programming?

On the other end of the spectrum, we have data oriented programming (DOP). One good example of a DOP language is Lisp. In this paradigm, everything is data, including code. Wait a minute, how is code “data”? Well, instead of writing out the sequence of steps like we do in other paradigms, we actually just describe the data here. If you have tried your hand at shell scripting, you would have come across awk and sed. They are good examples of data-driven languages.

Let’s talk about Lisp a bit more. Lisp stands for LISt Processing. It is a family of programming languages which emphasize data driven programming. In its most basic form, Lisp supports very few kinds of data. Here, “lists” is being the only way to group data. Clojure, a variant of Lisp, supports a few more types such as maps and sets. Instead of coupling data with functionality with an object system, DOP treats everything the same. Basically, many functions can act on just about any chunk of data. This way of thinking completely separates functionality and data, which is in stark contrast to OOP. In the DOP way of doing things, you build general-purpose functions that you compose together and then operate on homogenous data. What this means it that you lose the encapsulation feature. Also, polymorphism isn’t even relevant here since types have mostly disappeared.

Which one do I choose?

Most of us are introduced to programming with the OOP style. Remember how we started off with simple functional programming and gradually settled into OOP? So, because of that, we still tend to think in the OOP style. People who have worked on DOP think that it is cleaner! The syntax is terse and the structure is pure. They also seem to favor the multimethod-based dispatch as compared to the inheritance and polymorphism we get in OOP. This is actually a major plus in the world of programming. If you have been coding long enough, you would have seen enough junk to realize that the programming paradigm matters a lot. The way in which a language is designed affects the people who write code, which in turn affects the whole ecosystem.

That being said, there are many other features of OOP that are just hard to give up. The world, as we know today, is built mostly on OOP. This includes the web applications, the internet, enterprise software, networking protocols, and pretty much anything else important. There are definitely pros and cons to both OOP and DOP style. DOP is definitely better for some applications. When we are trying to represent real-world objects, a system that allows you to represent classes of things like people and trees makes sense. This is the OOP way of doing things. Once we get into the esoteric world of software, the object oriented metaphor isn’t quite as simple. OOP programmers tend to end up with big, complex hierarchies of types that can be pretty confusing. At least that’s what some people think! If you switch to a data-oriented approach, you can focus on exactly what you need to get done. But you will not get the strength of the OOP style.

At the end of the day, you cannot use the same knife for everything. I believe that different problems require different tools to solve, and programming style is no different. If you are encountering problems where you deal with a lot of homogeneous data, then by all means, use DOP. If you are creating an application where you have to deal with real world objects with dependencies and functionalities, the OOP style would be better. These problems lend themselves better to an OOP-based approach.

————————————————————————————————-