OOP Misunderstood, Misapplied

oop misunderstood

Object-oriented programming (OOP) was developed to tackle some fundamental problems that traditional programming typically struggled to solve. Though nearly every enterprise and modern programming language uses OOP, it’s often criticised for its complexity.

Things went out of hand when Elliot Suzdalnitski, a senior software engineer, published his controversial article calling OOP “a trillion-dollar disaster”. Suzdalnitski’s key argument was that most developers spend their precious time and brainpower thinking about “abstractions” and “design patterns” rather than solving real-world problems.

Its criticism stemmed primarily from how developers have approached OOP in the past. It was misunderstood as a solution to every problem, and that is where the problem started. This was almost akin to someone discovering a great hammer and then insisting on using it for everything—even when a screwdriver or wrench would work better.

A developer said on Reddit that the biggest issue with OOP is that some languages force you to use them for absolutely everything, even when they are not the best tool for the problem. So, a lot of the hate stems from people being forced to use them to solve problems that they are not well suited for.

“Just like any other paradigm, it is a useful tool when used to solve appropriate problems. But it is overused. In my opinion, the best languages are ones that embrace all the different paradigms and let you pick which one suits each situation the best,” he added.

OOP was designed to solve particular challenges and be a solution to particular problems. Its bad implementation or misunderstanding comes from new developers on legacy systems that choose not to dedicate the time and effort to understanding the original implementation.

Another developer mentioned that OOP was great as well as functional and the debate should be over a particular implementation, not the entire concept of OOP.

Inheritance – Is it Really a Problem?

Inheritance is one of the fundamental properties of OOP, where one class inherits properties and methods from another class (called the parent or superclass). A developer shared an example of AbstractMap, a part of the Java Collection Framework and how well it works using inheritance.

Imagine it this way: instead of building all map functionality from scratch, you “inherit” all the common functionalities from AbstractMap and write only the part unique to your implementation.

When you consider the practical benefits of inheritance in real-world development and implement it thoughtfully, inheritance provides a clean way to share common functionalities while maintaining type safety. It shines in scenarios where you have clear “is-a” relationships and well-defined interfaces.

A developer on Hacker News noted that “inheritance works best when the state in base classes is limited and the interface is quite clear. Ideally, where you are meant to override is also well defined”. This is particularly evident in framework development and API design.

Meanwhile, the software development community continues to refine its understanding of when and how to use inheritance effectively. A developer in favour of inheritance said, “Anyone saying ‘inheritance is bad’ is either a moron or really means ‘deep inheritance hierarchies are bad’ or maybe ‘bad designs are bad’.”

This more nuanced view reflects the growing maturity in how we approach object-oriented design.

The Enterprise Effect

No matter how much OOP is hated among developers, the fact is that Java’s meteoric rise in enterprise development cemented its position as the de facto standard. To date, enterprises are heavily dependent on Java because of the features it provides and OOP was the core of Java.

Thanks to its robust security features and benefits over other languages, Java became the language of choice for enterprises about 20 years ago. However, it’s not easy to change the tech stacks of enterprises where so much has already been invested.

Interestingly, a Reddit user suggested that we must stop comparing tech A with tech B. Enterprise and banking apps need longer lifetimes, sometimes even decades. They need to be built on tech, which has consistent development plans, external support, ease of maintenance, readability, extensibility, and availability of tools.

“All of the above can be easily achieved using the OOPs paradigm. Even with all its faults, Java enforces the OOPs in a better way,” he added.

The post OOP Misunderstood, Misapplied appeared first on AIM.

Follow us on Twitter, Facebook
0 0 votes
Article Rating
Subscribe
Notify of
guest
0 comments
Oldest
New Most Voted
Inline Feedbacks
View all comments

Latest stories

You might also like...