Disadvantage of OOP? [closed]

Question

Typically I don't want to know the specifics of the cons of OOPs, but it felt kind of weird when I had an argument at an interview I attended recently. The question that was posted to me was to tell me one disadvantage of object-oriented programming (OOP). At that time, I felt OOP to be the most matured level of programming after the procedural and functional models. So I replied to him that I don't see any negatives at all.

But the interviewer said there are few, and I asked him to list one if he does not mind. He gave an example that I don't digest well. He said that an OOP pattern does not strictly implement inheritance rules and cited the satellite/rocket example where the body parts will disintegrate periodically to remove weight during rocket launch and said that inheritance does not support this.

His example kind of felt very weird to me, the reason being the application of inheritance to this example.

I understand that the example he gave hardly had any sense at all, but I had this doubt -

Can we unplug class hierarchies dynamically (I am kind of confident in Java it's not possible) in an ideal object-oriented design?

Answer 1

Just because you have a hammer, doesn't mean everything is a nail.

I've found that many people often confuse when to apply composition vs. inheritance when using OOP as a programming style. The example you cite from the interview question appears to be a case of this exact kind of confusion.

One thing I've learned with experience, is that while inheritance is a nice paradigm for expression "IS-A" relationships between entities in a design, it's often better to favor composition rather than inheritance.

But let's examine the crux of the interviewers question though: when is OOP a poort choice of paradigm?.

OOP works best with large-scale, multi-developer, multi-module projects. For "development in the small" - such as scripting or transformative processing, it can require a good deal of overhead without necessarily adding value. But even in these cases, unless you're writing throw-away code, I would argue that large solution often evolve from smaller ones, so establishing structure and separation of concerns early on can save you grief later.

Ultimately, OOP programming also requires a certain level of design rigor and planning, as well as an understanding of the core principles of object orientation. If you're unwilling to take the time to study and understand those principles ... well, perhaps then OOP programming is not for you.

Beyond that, certain kinds of problems also lend themselves to alternative programming styles. For example, transformative processing is quite ammendable to the functional style of programming - in which a results is computed and passed to successive transformation steps to produce a final result. Problems where you have to search or query a domain for certain matching information are ammenable to query languages (like SQL) in which you describe your intent declaratively rather than imperatively.

Being able to recognize which kind of problem you are solving goes a long way towards choosing which kind of language or tool to use. The right tools can make a job much easier ... the wrong one can make it harder - or impossible.

Answer 2

I'm not fully understanding his example.

However, it's important to understand that OOP is very effective for things that can be modeled naturally with it, and is very ineffective for other things (e.g., crosscutting concerns or aspects). That is one disadvantage of OOP. Another is that it often incurs some runtime cost due to dynamic dispatching.

In addition, it is very easy to abuse OOP to do nonsensible abstractions. Having a rocket inherit from a body is one example. My experience is that novice developers either don't trust and don't use inheritance, or that they are over-eager and use it incorrectly, when other behaviors (like aggregation) are more appropriate. Over time, experience and understanding of the mechanism improve.

I'm not sure what he meant by "OOP pattern does not strictly implement inheritance rules", since OOP is not a pattern. One potential issue is that one can write a subtype that can violate Liskov's principle of substitution, so that an overridding method does not behave "at least" like the overridden method. There is no way to automatically check for this so it is possible to write code that violates OOP principles.

As for your final question "Can we unplug class hierarchies in an ideal Object Oriented Design?", I'm not sure what you mean here. If you're asking about changing the hierarchy at runtime, and making it so that a subtyping relation no longer exists from some point in the execution, then yes. It is possible with certain languages such as Smalltalk. Some would argue that this is "More OOP". In smalltalk, the 'methods' supported by a type are determined at the point of method call based on the current hierarchy and the current contents of each class. While I love smalltalk, this is one feature that I'm not crazy about, since I prefer compile-time checking with less runtime surprises.