Disadvantage of OOP?

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?

Solution 1

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.

Solution 2

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.

Solution 3

Although I agree with the interviewer's conclusion (OOP is flawed), his logic appears to be nonsense. It sounds like he's criticizing something he doesn't understand, because no competent OO programmer would make a rocket inherit from its thrusters.

People have made good criticisms against OOP, though. For example, Steve Yegge's Execution in the Kingdom of Nouns.

Solution 4

His example makes no sense. A rocket doesn't inherit from a body. It "has" a body. That's containment. So a some point you would "delete" the part attached to the rocket as it was jettisoned.

Solution 5

Although I don't fully understand the example given, as it sounds like composition to me I will give a disadvantage of OOP

OO is hard to test

• No direct access to read/write class variables/attributes - may need to introduce getters and seeters which breaks incapsulation.

• Inheritance can change the behavior of a method in a subclass

• Objects have state. It can be hard to generate these states as we depend on the public interface.

• Classes with loh cohesion can be hard to test as this could mean that the class does more than is specified.

View more solutions

Comments

[bragboy]

Yeah, i felt so, but see my question at the end..

[Robben_Ford_Fan_boy]

+1 His example just sounded like a text book composition example to me! I'd be curious to hear others interpretation though.

[baash05]

Jmucchiello pointed this one out.. The rocket has a segment, not is a segment. It might have several segments. When one becomes useless, delete it, and move on. :)

[Ken]

In prototype-based object-oriented languages, that's obviously a moot point. Yet even in class-based object-oriented languages, it's not always true: in Common Lisp, you can call change-class to change an object's class, without losing identity.

[Stephen C]

That is not a disadvantage of OOP. Rather, it is a limitation of some OOP languages. Other OOPLs do support higher order functions; e.g. Smalltalk-80.

[Jörg W Mittag]

@Stephen C: Actually, you could even go one step further and argue that languages that do not support HOFs are not OO. Why? In an object-oriented language, ideally everything should be an object. If everything is an object, this obviously means that functions must be objects. If functions are objects, they can be passed to and returned from methods. Presto: higher-order functions.

[Stephen C]

@Jorg - you could ... but I wouldn't, because this leads to endless pointless arguments about which of the many conflicting definitions of OO is "correct".

[wisty]

Once again, that's composition vs inheritance. A "has a" (person X has a course they are enrolled in) may be better than Student inheriting from Person.

[Jörg W Mittag]

@Stephen C: Yes, you're right, of course. I'm not really suggesting to do that. I just wanted to point out that the idea that OOP and HOF are somehow fundamentally incompatible, as this answer seems to suggest, is really not true. After all, what is a function but an object with only one method, call? (Which, incidentally, is actually how functions are implemented in Scala and Python, and how they are faked in Java (anonymous inner classes implementing single-method interfaces)).

[Jim L]

By definition they won't be perfect, or we wouldn't call them abstractions. :)

[Ken]

Jorg: Whenever someone says "Everything is an object", they never seem to define "everything". Data types? Methods? Symbols? Characters? Comments? Given any definition of "everything" I can imagine, I think there are both OO and non-OO languages that make that thing accessible. For example, while Ruby may not be my favorite language, I can't seriously claim that it's not OO just because its comments aren't objects.

[Donal Fellows]

Testing is where you may want to be using a Dependency Injection system so you can easily mock the bits that the class under test depends on. And whitebox tests are always going to be highly coupled to what they test; that should not be thought of as a problem. (Blackbox tests OTOH should only ever need the public interface.)

[tster]

+1 my favorite anti-java text.

[BlueRaja - Danny Pflughoeft]

A problem you create only as you get better stackoverflow.com/questions/2101875/… :)

[S.Jones]

+1 "Execution in the Kingdom of Nouns" is a classic. It's also one of the best ways to explain OO to English grads. :)

[JAB]

Going by your last paragraph, I'm guessing you don't like function pointers, either?

[Doradus]

Nice answer to a very vague question. OOP is really "noun-oriented programming", with the rationale that the nouns in a system change less often than the verbs. (A bank will always have accounts, customers, and employees, for example, but might not always support telegram-based money transfers.) In a system where the verbs are more stable than the nouns, another paradigm may lead to a more maintainable system.

[Qiulang]

I just asked a question about that article (14 years later). And as I expected it was closed immediately softwareengineering.stackexchange.com/questions/419122/…