Question

I’m trying to understand whether the answer to the following question is the same in all major OOP languages; and if not, then how do those languages differ.

Suppose I have class A that defines methods act and jump; method act calls method jump. A‘s subclass B overrides method jump (i.e., the appropriate syntax is used to ensure that whenever jump is called, the implementation in class B is used).

I have object b of class B. I want it to behave exactly as if it was of class A. In other words, I want the jump to be performed using the implementation in A. What are my options in different languages?

For example, can I achieve this with some form of downcasting? Or perhaps by creating a proxy object that knows which methods to call?

I would want to avoid creating a brand new object of class A and carefully setting up the sharing of internal state between a and b because that’s obviously not future-proof, and complicated. I would also want to avoid copying the state of b into a brand new object of class A because there might be a lot of data to copy.

UPDATE

I asked this question specifically about Python, but it seems this is impossible to achieve in Python and technically it can be done… kinda..

It appears that apart from technical feasibility, there’s a strong argument against doing this from a design perspective. I’m asking about that in a separate question.

Answer 1

The comments reiterated: Prefer composition over inheritance.

Inheritance works well when your subclasses have well defined behavioural differences from their superclass, but you’ll frequently hit a point where that model gets awkward or stops making sense. At that point, you need to reconsider your design.

Composition is usually the better solution. Delegating your object’s varying behaviour to a different object (or objects) may reduce or eliminate your need for subclassing.

In your case, the behavioural differences between class A and class B could be encapsulated in the Strategy pattern. You could then change the behaviour of class A (and class B, if still required) at the instance level, simply by assigning a new strategy.

The Strategy pattern may require more code in the short run, but it’s clean and maintainable. Method swizzling, monkey patching, and all those cool things that allow us to poke around in our specific language implementation are fun, but the potential for unexpected side effects is high and the code tends to be difficult to maintain.