Is OOP (Object Oriented Programming) dying? Should we stop to use OOP? This question is asked by many programmers. I can't count the number of post about "why OOP are great" or "No stop! It is a trap!". I wanted to contribute to this happy debate!
Why OOP is criticized?
Yesterday, I read this quite interesting blog post written by "Charles Scalfani".
He is an experimented Software Developer who developed with OOP during decades. Here, he focused on the "Three Pillars of the Paradigm": Inheritance, Encapsulation and Polymorphism.
Of course, OOP is criticized because it is a popular programming style! During this post, I will review some arguments gave by Charles Scalfani and offer my opinion. Here we go!
First, the Inheritance
Inheritance is the biggest benefit of the Oriented Object Paradigm. It sounds perfect for reusing and avoid duplicate codes.
Looks great ! Let's use inheritance to guaranties clean code and easy reuse!
...
No, we cannot use inheritance everywhere. Bad usage and mastery of inheritance is WORSE than no inheritance.
Banana Jungle Monkey - The reuse killer in OOP
During my carrier, I worked on an old Software developed in C++ with about 500.000 lines of code. The code was terrible and needed refactoring. During a featured development, we said: "Hey, we could take this class for inheritance, it is perfect!"
OK, let's inherit this class... Hugh... It needs another class... OK, let's take this.
And another class... And two others... Oh damned, we need an entire framework now...
And then, the situation was so complicated that we needed to create a new class. Goodbye reuse, welcome to duplicated code!
I agree with Charles Scalfani about inheritance. Moreover, he gave a great quote from Joe Armstrong, creator of Erlang:
The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
Joe Armstrong // creator of Erlang
For a simple compatibility, we got all the environment around this class.
Too many inheritances in a Software can limit reuse. This kind of code can be hard to read.
Limit the inheritance issue in OOP.
Several solutions exist to limit bad inheritance designs in OOP:
- Composition over inheritance. Containing instances of other classes that implement the desired function rather than inheritance. This is the solution against the Diamond Problem in many OOP languages. True for languages which doesn't support multiple inheritance, like Java.
- Develop a class and inheritance hierarchy. External documents which are hard to maintain...
In result, we delegate and limit the usage of inheritance to avoid those kinds of issue.
Unlucky! Inheritance has so many drawbacks...
I featured here only one of the potential issues by using inheritance.
- Bugs because implementation in the based class changed.
- Inheritance of objects which inherits of 6 others... Hard to maintain and read.
- External documentation to maintain a readable scheme.
Inheritance is hard to maintain and can conduct to bad design. To avoid a huge quantity of documents and comments, inheritance should be limited.
Second, the Encapsulation.
In this part, I don't agree with the author.
Encapsulation is great. Structuring data in objects is one of the best benefit of OOP.
Of course, there is the "Reference Problem". But this issue can be resolved by using a deep copy. Look easy to implement!
Passing object by reference can lead terrible after comes in security. Simple discipline and knowledge to limit those kinds of errors.
Third, Polymorphism in OOP.
Another part where I don't agree...
I used polymorphism for reuse code when inheritance fitted well.
It can save a lot of time by using methods still tested and approved.
Fourth? The missing pillar: Abstraction.
Abstraction is the fourth pillar. It is an extension of encapsulation.
OOP manages well the abstraction (hiding the information!). It suits well to reduce complexity by showing only necessary information. It helps to expose only necessary details.
I don't see any important default concerning abstraction...
The four pillars are alive... But...
OOP fails about potential issues leading to heavy design. OOP is not a principle easy to learn, concepts introduced are more complex than functional programming.
Moreover, the code can be heavy by introducing artificial classes... OOP fits well for organization. But this organization can be a trap, leading to the other defaults of OOP:
- Risk of processing time limited.
- Program larges in size.
- Risk of not relevant classes.
- ...
Is OOP dying?
Quick answer: No.
Oriented Object Programming is still a good tool for several reasons:
- Code reusable thanks to inheritance.
- Modularity thanks to encapsulation.
- Flexibility thanks to polymorphism.
- Security thanks to abstraction.
Of course, some tools (like inheritance) should be used with precaution... All along this post, I criticized the "inheritance principle". But inheritance issues are resolved by using great and clean designs.
When issues occur with OOP, it is due to flawed architecture.
Despite this, I found the blog post introduced interesting: Even if it looks exaggerated, it shows why OOP is not perfect.
Yes, OOP is not perfect and is not a solution all kind of problems. Sometimes, it is better to use another programming style:
- Functional programming.
- Logic programming .
- Procedure-based programming.
- etc.