In this episode, we will see

how polymorphism

complements abstraction very well and how it allows us

to better define classes on an abstract level.

But first, let's go over a few reminders on polymorphism.

"Subtype polymorphism", to be precise, [TN: sometimes a.k.a. "inclusion polymorphism" or "dynamic polymorphism"]

refers to the fact that instances of a subclass,

which can substitute for instances of the superclass,

keep their own properties

instead of being considered as having the properties of the superclass

especially with regards to their behavior,

that is, the methods to be invoked

will be determined at runtime

depending on the actual nature of the instances involved.

The definition may seem complicated

but the principle is actually quite simple.

For example, if I have a general class called "Personnage" (TN: means "Character")

with a subclass "Voleur" (TN: means "Thief"): a thief is indeed a character.

We also have "Magicien", "Guerrier", (TN: "Magician", "Warrior"), etc.

Magicians, warriors and thieves,

even if they are all characters,

will be able to behave as different instances,

for example when they meet.

For example, if a thief meets another character

he might steal from him;

if a warrior meets another character,

he might hit him, etc.

So for example

if I have a character "p1" who meets a character "p2",

the "rencontrer" method here (TN: "rencontrer" means "meet")

will adapt to the real nature of the instance "p1"

and will thus meet "p2" as a thief

if "p1" is a "Thief", as a magician if "p1" is a "Magician",

or as a warrior if "p1" is a "Warrior".

And remember that to have polymorphism

you need inheritance to have this general class

with regards to which the methods will adapt

depending on the specific subclasses. Inheritance thus,

but also dynamic binding.

Remember, too, that dynamic binding

consists in calling the right method

depending on the instance. So to go back to an example

from a previous episode,

imagine that we organize a meet-up

between a warrior and a thief.

This method here organizes a meeting

between two characters taken as arguments

and displays a message

and calls the "rencontrer" method

of character 'a', which is the first argument received here,

with character 'b', received as the second argument here.

And dynamic binding will ensure that when

we meet a warrior 'g' as the parameter 'a',

it is the "rencontrer" method of the warrior ("Guerrier")

which will, dynamically, during the execution of this piece of code,

check that 'a' is a warrior

to call the "rencontrer" method of the "Guerrier" class

and not the "rencontrer" method of the "Personnage" class, despite the fact

that 'a' is described as a "Personnage" here,

If we called the "rencontrer" method of the "Personnage" class

which would be a static binding

depending only on what is written statically,

whereas what happens in Java is dynamic binding

where we will call the "rencontrer" method

of the instance which is passed.

We look at what the instance is: it is a "Guerrier" (warrior),

so here we will call the "rencontrer" method of the "Guerrier" class.

That's it for reminders.

Let's now see how these ingredients,

how polymorphism, will allow us to better specify

our programs at a more abstract level

by introducing this notion of abstract classes

and abstract methods.

Let's start by presenting the problem that these abstract

methods address.

At the highest level of a hierarchy,

we don't necessarily know how to define a method

which we know will exist for all the subclasses

For example, if we imagine a very general class

representing nondescript, closed geometric shapes,

Then, in this class

it will be quite difficult to define

how to calculate its surface area.

Calculating the surface area of a nondescript geometric figure

is certainly something that is hard to define,

we wouldn't really know how to do it.

However, we know that for all closed figures,

for example circles, which are closed figures,

we know that for each specific closed figure

we should be able to defined a "surface" method.

So, we imagine that in all of these closed geometric figures,

we will have a "surface" method,

even if we don't know how to define it at the most abstract level.

And yet, to push the problem a little further yet,

we can even imagine that this "surface" method would

be used at the highest level,

for example to calculate the volume occupied

by a surface over a given height.

This volume

would depend on the height and on the geometric figure

and would be defined as the product of the height

multiplied by the surface of the close figure.

So we could even call this method

without knowing how we would define it

at the highest level. It would be defined

for all the actual cases of closed figures.

The correct way of doing this,

of coding a method which we know must exist

but which we do not necessarily know how to define

at the superclass level,

is to introduce the method

as an "abstract method".

Let's illustrate once more this concept of "abstract methods"

using another example; so, let's go back to

character games, where we have

warriors, who are characters [inheritance],

magicians, who also are characters [inheritance],

thieves, etc.

The class "Jeu" (TN: means "game") would of course contain several characters,

here we decided to put them in a dynamic array of characters.

And imagine that in the game, we wish

to display the whole set of characters.

So of course, we would write a loop

iterating over the set of characters,

this "persos" array here.

And for each of these characters,

we would display this very character.

The problem is, how do we display a generic character?

We don't know how to display a generic character.

We certainly know how to display a warrior,

we certainly know how to display a magician

or a thief.

So each of the specialized subclasses knows how it should be displayed

but at the general level of a character,

we don't necessarily know how to display it.

However, we know that we need to. Here, at the very general level of the game,

we know we will need to display characters.

So how do we do this?

Of course, if we do nothing at the level of the "Personnage" class,

if we don't define the "afficher" method (TN: means "display") in "Personnage"

then the code "afficher" in "Jeu" will not compile

since we are calling the "afficher" method of a "Personnage"

and the compiler would not know what to do

Thus, it would throw an error.

So, in order to be able to write this at the global level of the game,

we must define an "afficher" method in each "Personnage" class.

Moreover, we would like to impose to each of the subclasses,

to warriors and magicians, to display themselves

with their own "afficher" method.

We would like them to have a specific method

and we would like for this specific method to be called

when we make a general call here at the game level.

Basically, we want to force the subclasses to have a specific method

and we want this method to be polymorphic.

But how do we do this if we don't know,

suppose that we don't know how to display a generic character?

Moreover, how do we impose

the fact that this "afficher" method must be redefined?

How do we force its re-definition in the subclasses?

First solution for the first problem:

how to define the display for a generic character.

One way would be to have some arbitrarily-defined method,

for example, suppose that here, arbitrarily,

we define that the display for a generic character

is no display at all.

This solution is a really, really bad idea

because first, it is a bad model of reality,

characters should not be displayed as nothing

so it doesn't correspond to anything,

the display is incorrect. And on top of that,

the display would be incorrect if a subclass

were to forget to redefine the method,

so we would have some characters that would not be displayed,

phantom characters, and this would be rather inconvenient for the game.

What's more, this solution does not address the second problem,

it does not force the subclasses to redefine

their own "afficher" methods.

The only good solution

is thus to signal that the "afficher" method must exist

and must be redefined in each of the subclasses

This is known as an "abstract method".

So you have a second example,

which, I hope, allows you to understand

the point of having abstract methods

such as this one, defined at the level of superclasses, of abstract classes.

Now, let's see how this is actually written in Java.

To have an abstract method in Java,

we simply prepend the reserved keyword "abstract" to its header

and we simply end this header

with a semicolon ( ; ) without writing a body,

without giving it any definition

because abstract methods don't have a definition

in the class in which they were introduced.

They simply serve to impose to the subclasses

which we do not want to define as being abstract

-- we will come back to this in a moment --

that they should redefine this inherited abstract method.

And these methods must be contained within an abstract class,

and again we will come back to this in a moment,

and an abstract class is a class

which also has the "abstract" keyword in its header.

So for example here,

we want the "Personnage" class to be an abstract class

so we will add the "abstract" keyword to the header like so,

at the beginning of the class header

and it will contain an abstract method,

such as the method "abstract afficher" here.

If we go back to our example with the closed figures,

remember that the idea was to have closed figures

to define a "surface" method.

But we do not know how to define this "surface" method

in a general way at the level of the "FigureFermee" class

and so this "surface" method becomes an abstract method

and the "FigureFermee" class becomes an abstract class

and we imagine that we will have concrete subclasses

defining closed figures such as a circle, for example.

Since the "FigureFermee" is an abstract class,

we add the "abstract" keyword here.

The class contains two methods

we added another abstract one here.

So we have the "surface" method we were talking about earlier on in our example

to which we added the "abstract" keyword,

and we could also imagine

that we will have a "perimetre" method

which would return the perimeter of a closed figure

and which we do not know how to define in a general way

at the level of the closed figures,

so it is also an abstract method.

Remember that you can use, in an abstract class,

an abstract method within a non-abstract method.

So for example here,

calculating the volume generated by the surface of the closed figure

over a certain height passed as a parameter here

would consist in calculating the product of the height and the value

returned by the abstract method "surface". This is quite possible.

So an abstract class,

qualified by the keyword "abstract" at the beginning of its header:

"abstract class something",

is a class that cannot be instantiated

and that contains at least one abstract method.

This is why it is known as an abstract class,

because we cannot create an instance of it

So for example, if I wanted to write "FigureFermee"

to declare an instance of a closed figure,

e.g " fig = new ... "

followed by a FigureFermee constructor,

I would not be able to do this, the compiler would prevent me from doing so

since "FigureFermee" is an abstract class,

meaning that I cannot create an instance of it.

And subclasses of an abstract class

stay abstract as long as they haven't redefined

all of its abstract methods.

That is, they remain abstract

as long as at least one inherited abstract class

hasn't been defined.

Let's take an example,

the example of the game with its characters,

where "Personnage" is an abstract class

which contains an abstract method "afficher".

"Guerrier" is a subclass of "Personnage".

Imagine that "Guerrier" forgets

to redefine the abstract method "afficher" from "Personnage".

If I do the following:

so, if I create a game and I try to add

a new warrior to the game,

if "Guerrier" has forgotten to redefine the abstract method from "Personnage"

then "Guerrier" is also an abstract class

and I will not be able to create an instance of it,

of this abstract class "Personnage".

If I try to do this, I will get the message:

"Guerrier is abstract; cannot be instantiated".

I cannot create an instance of the abstract class "Guerrier"

which is still abstract since it did not

redefine the "afficher" method.

If I take a second example on the closed figures,

let's imagine that we still have this abstract class "FigureFermee"

with its abstract methods "surface" and ...

...

"perimetre", which is also abstract,

and suppose that we define a class like so, "Cercle" [TN: means "Circle"],

inheriting from "FigureFermee".

This "Cercle" class

redefines the "surface" method here concretely,

in a non-abstract way,

for example, Pi times the radius squared

and it also redefines the "perimetre" method concretely.

It has thus redefined both abstract methods

inherited from its abstract superclass "FigureFermee"

and so this "Cercle" class is no longer an abstract class,

we are able to create instances of "Cercle".

This is now possible

because the "Cercle" class is no longer abstract.

However, let's imagine a "Polygone" class

also inheriting from the "FigureFermee" class

but which redefines only the perimeter, for example,

supposing that we calculate the perimeter of a polygon

as being the sum of the lengths of its sides.

So we know perfectly well how to define this

but we would not necessarily know how to define in a general way

the surface of a polygon, and so the "Polygon" class

would only redefine the abstract method "perimetre"

but would not redefine the abstract method "surface".

And so to "Polygone" class would remain an abstract class.

I would not be able to create any instance of "Polygone".

This is impossible because

"Polygone" is an abstract class

since it doesn't redefine the abstract method "surface".

By the way, there is something missing here

to make the code for "Polygone" correct --

do you know what it is?

There, this concludes this episode on abstract methods

and abstract classes.

The next episode will focus on different aspects

of polymorphism, constructors,

the "Object" superclass, etc.

Classes et méthodes abstraites

Introduction à la programmation orientée objet (en Java)

Meet the Instructors