Disadvantage of OOP? [closed]

Answer 1

Take a look at these articles. There are various explanations of some of the disadvantages of OOP, particularly the hazards of forcing things into hierarchies, like in your interviewer's example.

Answer 2

maybe something like circle-ellipse problem

Answer 3

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.

Answer 4

One way to model an object which changes its sub-class is to use the State pattern. Using your interview question and some help from Wikipedia, here's some Java code that shows how you could model the state transitions as the rocket goes through its various stages. I haven't shown the Command Module stages but they follow a similar pattern through lunar descent, lunar ascent, lunar orbit rendezvous and the return to Earth. You could probably find much more interesting behaviours to add to the ISpaceShipState interface.

public class SpaceShip {
    private ISpaceShipState m_state = new SaturnFiveState();

    public void setState(ISpaceShipState state) {
        m_state = state;
    }

    public void jettison() {
        m_state = m_state.transition();
    }

    public int getStageNumber() {
        return m_stage.getStageNumber();
    }

    public int getNumberOfRocketMotors() {
        return m_stage.getNumberOfRocketMotors();
    }

    public String getRocketMotorTypeName() {
        return m_stage.getRocketMotorTypeName();
    }
}

interface ISpaceShipState {
    public ISpaceShipState transition();
    public int             getStageNumber();
    public int             getNumberOfRocketMotors();
    public String          getRocketMotorTypeName();
}

public class SaturnFiveState implements ISpaceShipState {
    public ISpaceShipState transition() {
        return new SaturnFiveSecondStageState();
    }

    public int getStageNumber() {
        return 1;
    }

    public int getNumberOfRocketMotors() {
        return 5;
    }

    public String getRocketMotorTypeName() {
        return "F-1";
    }
}

public class SaturnFiveSecondStageState implements ISpaceShipState {
    public ISpaceShipState transition() {
        return new SaturnFiveThirdStageState();
    }

    public int getStageNumber() {
        return 2;
    }

    public int getNumberOfRocketMotors() {
        return 5;
    }

    public String getRocketMotorTypeName() {
        return "J-2";
    }
}

public class SaturnFiveThirdStageState implements ISpaceShipState {
    public ISpaceShipState transition() {
        return new SaturnFiveCommandModuleState();
    }

    public int getStageNumber() {
        return 3;
    }

    public int getNumberOfRocketMotors() {
        return 1;
    }

    public String getRocketMotorTypeName() {
        return "J-2";
    }
}

Can we unplug class hierarchies in dynamically (I am kind of confident in Java its not possible) in an ideal Object Oriented Design?

It is possible to simulate dynamic typing in Java using reflection, although the code is very clumsy compared to the same thing in a dynamically typed language.

Answer 5

The classic is to prefer composition over inheritance. Inheritance is there to capture abstractions along a seam that your system varies along.

If you don't quite clearly capture that abstraction, then yes, you will get strange forces on your designs. But this is a problem of programming in world where the abstractions are not quite right for what you are trying to achieve. Not that they will ever be perfect.

Answer 6

I can kinda see the point he was driving at. I think the argument was basically centred around the disadvantage of inheritance - if you're not careful, or if you inherit too many times to keep extending functionality you can end up with a bloated mess of a class with a load of redundant features and lack of cohesion.

His analogy works if you consider that, once the rocket has burned the fuel in a segment, the segment becomes redundant and therefore dead-weight. The rocket can jettison the segment, but I don't think it's possible to exclude sections of a class you don't want to inherit (although correct me if I'm wrong, because it sounds useful).