Disadvantage of OOP? [closed]

Answer 1

Concerning unneeded methods in parent classes: Aren't they a sign of bad architecture? I mean shouldn't you isolate in the planing stage functionalities needed by each class and then have a chain of classes derived one from another?

For example we have class A, B, C and D. Class A has methods classes B, C and D need. Class B has methods class D needs. So we could derive class D from B and B from A. On the other hand we will derive C from A because C doesn't need the stuff B has. So we basically solved problem of having unneeded stuff by adding one extra class in hierarchy. Of course if something like this wasn't caught in the planning stage and class B was used as base class, it would be more difficult to split class B into two classes, but with some extra effort the problem of unneeded baggage is solved.

Answer 2

I think it's main disadvantage comes straight from its power. One of the most common things done in OOP is to replace parent classes with derived classes in some places, to specialise the behaviour of the code. Well, if not done carefully, it's easy to invalidate some of the assumptions made in the caller code; and that could be very difficult to spot while reviewing the code, because the types you're seeing declared are not the ones actually being used.

In brief: polymorphism can be made not explicit and thus easy to overlook weird behaviours in the derived classes.

Answer 3

The biggest disadvantage I can think of with OOP is lack of support for higher order functions. Although you can pass in an object containing a method, this is verbose and inefficient. It would be much better to be able to pass in a function directly to another function.

Answer 4

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.

Answer 5

I'm sure I've never heard of a statically typed language like Java that is capable of morphing an object into another while leaving the object reference intact, but I'm sure you can fake it with delegates etc. That said, without some fundamentally good thought, it probably would be a mess.

I can't know how the interviewer presented the question or how you responded, but one of OOP's biggest short comings isn't really OOP itself. It's the poor usage of OOP and bad "IS-A" relationships people try to create. If the only reason you can come up with to create an inheritance hierarchy is reuse of code, it's a poor reason. AOP can be argued to be a better approach for that. (before you flame or down vote, please note I said "can be")

OOP is about the interface and type, not about the implementation. Knowing that an object can return a list of job candidates is all I need to know. Whether that comes from an RDBMS, column oriented db, web service, or even spreadsheet is immaterial. I know I can pass that object as a parameter to other methods and they can call "FetchJobCandidates" and know it will get job candidates. There are pitfalls along the way, but mostly if you think of classes based on what they expose to the rest of the world rather than what they do internally, you're on a better footing IMO.

Answer 6

Can we just say use this in OOP?

RocketShip.BodyPart1 = nothing or

RocketShip.BodyPart1.isDetached = false?

I believe it is not the OOP itself is the fault but it's the limitation(s) of the programming language used on how it is being implemented.