https://towardsdatascience.com/object-oriented-programming-is-dead-wait-really-db1f1f05cc44
If so many people are hating on object-oriented programming, why is it still so dominant? Photo by Vale Zmeykov on Unsplash
Programming in the 1960s had a big problem: computers weren’t that powerful yet, and somehow they needed to split the capacities between data structures and procedures.
This meant that if you had a large set of data, you couldn’t do that much with it without pushing a computer to its limits. On the other hand, if you needed to do a lot of things, you couldn’t use too much data or the computer would take forever.
Then Alan Kay came around in 1966 or 1967 and theorized that one could use encapsulated mini-computers that didn’t share their data, but rather communicated through messaging. This way, compute resources could be used much more economically.
Despite the ingenuity of the idea, it would take until 1981 until object-oriented programming hit the mainstream. Since then, however, it hasn’t stopped attracting new and seasoned software developers alike. The market for object-oriented programmers is as busy as ever.
But in recent years, the decade-old paradigm has received more and more criticism. Could it be that, four decades after object-oriented programming hit the masses, technology is outgrowing this paradigm?
The main idea behind object-oriented programming is as simple as can be: you try to break a program in parts that are as powerful as the whole. It follows that you couple pieces of data and those functions that only get used on the data in question.
Note that this only covers the notion of encapsulation, that is, data and functions that sit inside an object are invisible to the outside. One can only interact with the contents of an object through messages, typically called getter and setter functions.
What is not contained in the initial idea, but is considered essential to object-oriented programming today, are inheritance and polymorphism. Inheritance basically means that developers can define subclasses that have all the properties that their parent class has. This wasn’t introduced to object-oriented programming until 1976, a decade after its conception.
Polymorphism came to object-oriented programming another decade later. In basic terms, it means that a method or an object can serve as a template for others. In a sense it’s a generalization of inheritance, because not all properties of the original method or object need to be transmitted to the new entity; instead, you can choose to override properties.
What’s special about polymorphism is that even if two entities depend on each other in the source code, a called entity works more like a plugin. This makes life easier for developers because they don’t have to worry about dependencies at runtime.
It’s worth mentioning that inheritance and polymorphism aren’t exclusive to object-oriented programming. The real differentiator is encapsulating pieces of data and the methods that belong to them. In a time where compute resources were a lot scarcer than today, this was a genius idea.
Object-oriented programming wasn’t a dumb idea. It made coding a lot easier. Photo by Windows on Unsplash
Once object-oriented programming hit the masses, it transformed the way developers see code. What prevailed before the 1980s, procedural programming, was very machine-oriented. Developers needed to know quite a bit about how computers work to write good code.
By encapsulating data and methods, object-oriented programming made software development more human-centered. It matches human intuition that the method drive() belongs to the data group car, but not to the group teddybear.