How to handle the methods that have been added for subtypes in the context of polymorphism?

Question

When you use the concept of polymorphism you create a class hierarchy and using parents reference you call the interface functions without knowing which specific type has the object. This is great. Example:

You have collection of animals and you call on all animals function eat and you don't care if it is a dog eating or a cat. But in the same class hierarchy you have animals that have additional - other than inherited and implemented from class Animal, e.g. makeEggs, getBackFromTheFreezedState and so on. So in some cases in you function you might want to know the specific type to call additional behaviours.

For example, in case it is morning time and if it is just an animal then you call eat, otherwise if it is a human, then call first washHands, getDressed and only then call eat. How to handle this cases? Polymorphism dies. You need to find out the type of the object, which sounds like a code smell. Is there a common approach to handle this cases?

Answer 1

Depends. Unfortunately there is no generic solution. Think about your requirements and try to figure out what these things should do.

For example, you said in the morning different animals do different stuff. How about you introduce a method getUp() or prepareForDay() or something like that. Then you can continue with polymorphism and let each animal execute its morning routine.

If you want to differentiate among animals, then you should not store them indiscriminately in a list.

If nothing else works, then you could try the Visitor Pattern, which is kind-of a hack to allow for kind-of a dynamic dispatching where you can submit a visitor that will receive type-exact callbacks from animals. I would stress however that this should be a last resort if everything else fails.

Answer 2

This is a good question and it's the kind of trouble a lot of people when trying to understand how to use OO. I think most developers struggle with this. I wish I could say that most get past it but I'm not sure that's the case. Most developers, in my experience, end up using pseudo-OO property bags.

First, let me be clear. This is not your fault. The way OO is typically taught is highly flawed. The Animal example is the premier offender, IMO. Basically, we say, let's talk about objects, what can they do. An Animal can eat() and it can speak(). Super. Now create some animals and code how they eat and speak. Now you know OO, right?

The problem is that this is coming at OO from the wrong direction. Why are there animals in this program and why do they need to speak and eat?

I have a hard time thinking of a real use for an Animal type. I'm sure it exists but let's discuss something that I think is easier to reason about: a traffic simulation. Assume we want to model traffic in various scenarios. Here are some basic things that we need to have to be able to do that.

Vehicle
Road
Signal

We can go deeper with all kinds of things pedestrians and trains but we'll keep it simple.

Let's consider Vehicle. What capabilities does the vehicle need? It needs to travel on a road. It needs to be able to stop at signals. It needs to be able navigate intersections.

interface Vehicle {
  move(Road road);
  navigate(Road... intersection);
}

This is probably too simple but it's a start. Now. What about all the other things that a vehicle might do? They can turn off of a road and into a ditch. Is that part of the simulation? No. Don't need it. Some cars and buses have hydraulics that allow them to bounce or kneel respectively. Is that part of the simulation? No. Don't need it. Most cars burn gasoline. Some don't. Is the power plant part of the simulation? No. Don't need it. Wheel size? Don't need it. GPS navigation? Infotainment system? Don't need em.

You only need to define behaviors that you are going to use. To that end, I think it's often better to build OO interfaces from the code that interacts with them. You start with an empty interface and then start writing the code that calls the non-existent methods. That's how you know what methods you need on your interface. Then once you've done that, you go and start defining classes that implement these behaviors. Behaviors that are not used are irrelevant and do not need to be defined.

The whole point of OO is that you can add new implementations of these interfaces later without changing the calling code. The only way that works is if the needs of the calling code determines what goes in the interface. There is no way to define all the behaviors of all the possible things that could be thought up later.

Answer 3

TL;DR:

Think about an abstraction and methods that apply to all subclasses and cover everything you need.

Let's first stay with your eat() example.

It's a property of being a human that, as a precondition to eating, humans want to wash their hands and get dressed before eating. If you want someone to come to you to eat breakfast with you, you don't tell them to wash their hands and get dressed, they do it on their own when you invite them, or they answer "No, I can't come over, I haven't washed my hands, and I'm not yet dressed".

Back to software:

As a Human instance won't eat without the preconditions, I'd have the Human's eat() method do washHands() and getDressed() if that hasn't been done. It shouldn't be your job as the eat() caller to know about that peculiarity. The stubborn-human's alternative would be to throw an exception ("I'm not prepared to eat!") if the preconditions aren't met, leaving you frustrated, but at least informed that eating didn't work.

What about makeEggs()?

I'd recommend to change your way of thinking. You probably want to execute the scheduled morning duties of all the beings. Again, as the caller it shouldn't be your job to know what their duties are. So I'd recommend a doMorningDuties() method that all classes implement.

Answer 4

The answer is quite simple.

How to handle objects that can do more than you expect?

You do not need to handle it because it would serve no purpose. An interface is usually designed depending on how it's going to be used. If your interface does not define washing hands, then you do not care about it as the interface caller; if you did you would have designed it differently.

For example, in case it is morning time and if it is just an animal then you call eat, otherwise if it is a human, then call first washHands, getDressed and only then call eat. How to handle this cases?

For example, in pseudocode:

interface IEater { void Eat(); }
interface IMorningRoutinePerformer { void DoMorningRoutine(); }
interface IAnimal : IEater, IMorningPerformer;
interface IHuman : IEater, IMorningPerformer; 
{
  void WashHands();
  void GetDressed();
}

void MorningTime()
{
   IList<IMorningRoutinePerformer> items = Service.GetMorningPerformers();
   foreach(item in items) { item.DoMorningRoutine(); }
}

Now you implement IMorningPerformer for Animal to just perform eating, and for Human you also implement it to wash hands and get dressed. Caller of your MorningTime method could care less if it's human or an animal. All it wants is the morning routine performed, which each object does admirably thanks to OO.

Polymorphism dies.

Or does it?

You need to find out the type of the object

Why are assuming that? I think this could be a wrong assumption.

Is there a common approach to handle this cases?

Yes, usually it's solved with carefully designed class or interface hierarchy. Note that in the example above there is nothing that contradicts your example as you've given it, yet, you probably will feel dissatisfied, because you've made some more assumptions that you did not write in the question as of the moment of writing, and these assumptions are probably violated.

It is possible to go to a rabbit hole by you tightening your assumptions and me modifying the answer to still satisfy them, but I do not think that would be useful.

Designing good class hierarchies is difficult and it requires a lot of insight into your business domain. For complex domains one goes over two, three or even more iterations, as they refine their understanding of how different entities in their business domain interact, until they arrive at an adequate model.

That's where simplistic animal examples are lacking. We want to teach simple, but the problem we are trying to solve is not obvious until you go deeper, that is have more complex considerations and domains.