Overriding, and the same call for different objects

What you will be able to do

After this lesson you can

• override a method in a child class,
• treat objects of different classes alike with the same call,
• extend a method with super(), and
• write a parent that expects its children to fill in a method.

Overriding

A child gets all the methods of its parent. But sometimes the parent's version is not right for the child. A dog does not make "a sound". It says Woof. The child can override the method: write a method with the same name. Python then uses the child's version for the child's objects.

Predict first. What does each of the four animals say? Then run it.

• Dog and Cat each write their own speak. For a dog, Python finds speak in Dog first, and uses it.
• Fish writes no speak, so Python goes up to Animal, and uses the parent's.
• Animal("Thing") uses Animal.speak.

The loop at the end is the important part. The same call, animal.speak(), gives a different answer for each kind of object. The loop does not ask "is it a dog or a cat?". It just calls speak, and each object does the right thing. This is called polymorphism, from Greek words for "many forms". It lets you write code that works for any animal, even one that does not exist yet. When someone adds a Bird class with its own speak, the loop works for birds without any change.

Extending, not only replacing

A child often wants to do what the parent does, and more. Then it calls the parent's version with super().

Notice that the overriding method here replaces the rule completely. If you wanted the parent's checks plus something more, you would call super().withdraw(amount) inside it.

The loop never asks what kind of shape it holds. Adding a new kind of shape needs a new class, not a change to the loop.

A parent that expects its children to fill in a method

Sometimes the parent cannot know how to do a job, but it knows that every child must. A Shape cannot find an area, but every Square and Circle can. The parent promises the method, and refuses to run it.

This pattern, a parent with a general method that calls a part that the children fill in, is used everywhere in real programs: in games (every enemy has an attack), in graphics (every shape has a draw), and in frameworks.

Common mistakes

• Mis-spelling the method name in the child, so that it does not override but adds a new method. The parent's version runs, and nobody notices. Check the spelling.
• Overriding with different parameters. A caller that works for the parent breaks for the child.
• Forgetting super() when the child should do the parent's part too.
• Using if type(x) == Dog to choose what to do. Let each class do its own job, and call the same method.
• Calling a method that the parent promised but a child forgot, and not catching the error.

Practice

Start with two quick questions. Each New numbers gives you a fresh one, so you can practise as long as you like.

Then the labs and the problems:

1. Warm-up. Open the problem Who says what? and write the output of a loop of different animals.
2. Build. Open the lab Shapes with areas. You build a parent and two children, and the checker tries all of them in one loop.
3. Stretch. Open the problem Add a Bird and add a class without changing the loop.

Remember these

• A child overrides a method by writing one with the same name.
• Polymorphism: the same call gives a different answer for different objects, and the code does not ask which kind it is.
• super().method(...) calls the parent's version, to extend it.
• A parent can promise a method with NotImplementedError, and its own methods can call it.

Check yourself

Try each one on your own first. If you are stuck, open a hint. Then check with Show the answer.

1. Which speak runs for Fish("Nemo") when Fish has none of its own?

2. What is polymorphism, in one sentence?

3. What does NotImplementedError in a parent mean?