Ce cours introduit la programmation orientée objet (encapsulation, abstration, héritage, polymorphisme) en l'illustrant en langage C++. Il présuppose connues les bases de la programmation (variables, types, boucles, fonctions, ...). Il est conçu comme la suite du cours « Initiation à la programmation (en C++) ». Comme son prédécesseur, ce cours s'appuie sur de nombreux éléments pédagogiques : vidéos sous-titrées, quizz dans et hors vidéos, exercices, devoirs notés automatiquement, notes de cours.
Polymorphisme : méthodes virtuelles
Loading...
Do curso por École Polytechnique Fédérale de Lausanne
Introduction à la programmation orientée objet (en C++)
180 classificações
École Polytechnique Fédérale de Lausanne
180 classificações
Na lição
Polymorphisme
Cette semaine nous abordons la quatrième et dernière notion fondamentale de la programmation orienté objet : le polymorphisme.
Conheça os instrutores
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
In the previous video, we learned
that polymorphism is a central concept in object-oriented programming.
We learned that to implement a polymorphic solution,
we need to make use of what is known as dynamic binding.
The goal of this episode is to show you how to implement dynamic binding
in C++ using virtual methods.
More specifically, we concluded the last episode
by stating that for dynamic binding to take place in C++,
two ingredients must be present.
First, the use of virtual methods
on references and pointers.
This episode will explain this concept.
Remember that we started with an example where we had a hierarchy
of classes in which a subclass, the Guerrier subclass,
overrides a method already defined in the superclass.
An object of the subclass type was assigned, via passing arguments,
to a variable of the superclass type.
We had then asked ourselves
which rencontrer method would be called here.
The rencontrer method of the superclass,
or the one of the subclass?
And we had seen that in C++,
static binding was used,
meaning that the type of the variable on which we call the method
determines which method will be called.
In C++, if we want dynamic binding
to be used, that is, if we want the contents of the variable
rather than its type determine which method to call,
then we must explicitly declare in the program that the method
must be dynamically bound.
And this is done by declaring this method
as virtual.
For dynamic binding to take place,
we thus have to declare this method as virtual, but it must also
work via a reference or a pointer.
This is the case here, <i>un</i> is a reference to the object passed as a parameter.
In C++, we must indicate explicitly to the compiler that a method
can use dynamic binding.
And this is done by declaring it as virtual.
This declaration must be made in the most general class
defining this method, that is, at the highest
in the hierarchy, in the original prototype.
So in the case of our example, in the Personnage class.
And to make a method virtual in C++, one simply prepends
the prototype of the method with the virtual keyword.
Note that any override in subclasses of a method
that was declared as virtual in the superclass will also be considered as being
virtual even if we don't add the virtual keyword
before its prototype.
So basically, if I have a superclass, A, containing a particular method
m, and if I have a subclass B which overrides this method.
If in the A superclass
the method m was declared as virtual,
then it will also be virtual in the subclass
even if the keyword isn't explicitly included.
If we go back to our first example, if we want our method to
benefit from dynamic binding,
then we should declare the method as virtual
in the superclass.
But is this really our original example?
If you have been attentive, you may have noticed
that the example that you see now
is a variation on the example presented initially.
A variation in which the arguments of the <i>faire_rencontrer</i> function
are passed by value.
We deliberately made this change to show you the effect
of not using a reference or a pointer
on dynamic binding.
The problem is that when we pass by value
the Guerrier object will be copied into a variable of type Personnage.
The rencontrer method will thus not apply to the original instance,
but to a copy of the instance in a variable of type Personnage.
Essentially, if we had an object of type Guerrier in the variable g,
once it is copied into the variable un, which is of type Personnage,
it will then be considered only as a Personnage.
Personnage doesn't have a member variable for a weapon, for example.
The object contained in the variable un
is indeed of type Personnage.
Therefore, even if the rencontrer method is virtual,
and can thus benefit from dynamic binding,
since the object contained in the variable is of type Personnage,
then the rencontrer method of
Personnage will always be called here.
As we mentioned in the previous episode,
for dynamic binding to be able to take place,
two conditions must be verified.
The first is that the methods must be virtual, as we have just discussed,
and the second is that these virtual methods
must apply to real instances
via references or pointers.
If we choose to pass by reference,
then when we pass the arguments, we will not copy them
into objects of type Personnage; we will simply indicate that un
is another name for the variable g.
This way, we allow the virtual method to work on the actual instance.
By allowing a virtual method to work on the real instance,
we obtain the behavior we want,
namely, dynamic binding.
As we said earlier, it is the combination of using references
and making the methods virtual that we obtained the desired result.
Here of course, we could make do with a constant reference as parameter
since the <i>faire_rencontrer</i> function
does not modify its parameter un.
This is how we should write the code in order to obtain
dynamic binding in the context of this example.
So, to allow a virtual method to operate on
the real instance, it is possible to use references.
We can also use pointers
as the following example will show.
And this time, to switch things up, here is a zoological example where
we have a subclass Dauphin (TN: means "Dolphin") inheriting from
a Mammifere superclass (TN: means "Mammal"). Each of these classes
has a default, explicit constructor and a destructor.
Mammals, in general, have a default method for eating (TN: "manger").
Dolphins have a specific method for this action.
And the same goes for the methods allowing the mammals or dolphins
to move (TN: "avancer").
Here is a small main program which uses the class
hierarchy that you have just seen.
Let's study its execution step-by-step to see what output it will produce.
The first line of the program declares a variable named lui (TN: "lui" means "him"),
which is a pointer to a Mammifere.
This variable takes the address of an object of type Dauphin allocated dynamically.
The object of type Dauphin, allocated dynamically, is constructed using
the default constructor of the Dauphin class.
The lui variable thus contains the address of an object of type Dauphin.
The default constructor of the Dauphin class was used here
to construct this object.
This is the default constructor,
as defined in the Dauphin subclass.
Note that the constructor of a subclass always invokes
the constructor of the superclass.
If it doesn't do so explicitly, then it is the default constructor
of the superclass that is called.
This means that, before the "Coui, Couic !" message is displayed,
the message "Un nouveau mammifère est né!" is displayed (TN: means "new mammal born").
The execution of this line of code will therefore output the following:
A new mammal is born! Why?
Because the default constructor of the Dauphin class
implicitly called the default constructor of the Mammifere class.
The constructor of the Mammifere superclass was invoked
by Dauphin's one.
When its execution is done,
the body of Dauphin's constructor will be executed,
producing the following output.
Second line.
We apply to the object pointed to by the lui pointer,
that is, this object here, the avancer method.
Note that here, since we use pointers,
we allow the method to be applied
to the actual instance pointed to by the object,
and thus to have polymorphism.
Remember that the notation "lui->avancer()"
is equivalent to writing "(*lui).avancer()"
We access the contents of the object pointed to by lui,
and call the avancer method on this object.
The avancer method is defined as virtual in the superclass
and overridden in the Dauphin subclass.
Since we allow this virtual method
to act directly on the actual instance via the pointer,
dynamic binding is used and it is Dauphin's avancer method
which is called.
Therefore, the message "Je nage" (TN: means "I am swimming") will be displayed here,
and at this stage, we have the following output.
Let's move on to the next line, where the manger method is called
on the object pointed to by lui.
The manger method is indeed overridden in the Dauphin class but careful,
unlike the previous case, the manger method
was not declared as virtual in the superclass.
The manger method is indeed called via a pointer
but this is only one of the two ingredients
necessary for dynamic binding. The pointer is there,
but the method is not virtual,
which means that we cannot have
dynamic binding.
In this case, it is the type of the variable which wins.
lui is a pointer to Mammifere,
so the object it points to is perceived as an object of type Mammifere.
Static binding thus occurs in this case
and it is the manger method of Mammifere which will be called here.
The output after execution of this statement will thus be:
"Miam... croumf !", which is the message displayed by Mammifere's manger method.
Let's go to the next line.
"delete lui" means that we free the memory area allocated
dynamically at this stage of the program.
This means, basically, that we recover the memory area associated
with the object of type Dauphin previously allocated.
"delete lui" causes this object's life to end and since its lifetime is up,
the destructor is called.
But which destructor exactly is called?
If we examine the code of the Mammifere class,
we can see that the destructor was declared as virtual.
This means that this method, if called via a pointer
for example, will benefit from dynamic binding.
The destructor is indeed called via a pointer, which means that
dynamic binding will take place for destruction as well.
The object will be perceived according to its real nature,
that is, as a Dauphin,
and it is Dauphin's destructor which will be called,
causing the following output.
We learned in a previous episode that the order in which destructors are called
is the inverse of the orders for constructors.
So to create an object of type Dauphin,
the constructor of the Mammifere supercalss was called, then Dauphin's constructor.
For destruction, it is the opposite,
we will first call Dauphin's constructor,
then Mammifere's destructor.
Now, let's imagine that the destructor of the Mammifere class
was not declared as virtual.
Since the destructor was not declared as virtual in the Mammifere class,
the call that is made here cannot be dynamically bound.
This means that the type of the variable will win
for the choice of the destructor method,
and it is this destructor here that will be called rather than this one.
So essentially, if the destructor for Mammifere
had not been declared as virtual in our example,
then only Mammifere's destructor would have been invoked
and Dauphin's one would not have been.
Meaning that the object that was allocated dynamically in our program
with a type of Dauphin would be only partially destroyed.
Only the part of the Dauphin which is a Mammifere would have been destroyed here.
If the object of type Dauphin dynamically allocated here
had required a certain amount of resources,
then these resources would not have been freed correctly.
To summarize, when a virtual method is called via a reference
or a pointer, that is, when both of these ingredients are present,
then the choice of the method will be made based on the actual type of the instance.
This is known as dynamic binding.
But watch out, here are a few important points to consider regarding virtuality
in the context of construction and destruction.
As we discussed in the example of Mammifere and Dauphin,
to avoid having a partial destruction only,
it is recommended to always declare destructors as virtual.
However, since a constructor is always designed to
initialize the current instance, it cannot be virtual.
If it calls virtual methods,
then the virtual aspect of these methods will simply be ignored.
This is an advanced concept -- let's see what it means in a concrete example.
Here is an somewhat academic example that will explain
what happens in this case
where we have a superclass A of which the B subclass inherits.
Both classes have a method m which happens to be virtual
and is hence overridden in the B subclass.
When we execute this line of code, the default constructor for
the A class is called, and calls in turn the method f.
The method f is called on the this object, which is of type A,
and so we will of course invoke the f method of the A class,
which will display the following.
On the second line, we create an object of type B.
There is no explicit constructor in the B class,
and so the default constructor will be invoked,
and it will invoke the default constructor of the superclass.
The f method therefore now applies to a "this" object of type B.
However, the virtual aspect of the method is completely ignored
in a constructor.
So this aspect is not taken into account, and it is still the current class's
method which is called.
Therefore, when this second line is executed,
we will also have the following output.
The next line of code declared a variable pa of type pointer-to-A,
and initializes is with the address of the object b.
The f method is then called on the object pointed to by the pa pointer,
which is an object of type B.
Here, both ingredients necessary
to dynamic binding are present.
We have a virtual method f which is invoked via a pointer.
The f method will thus be chosen
depending on the real nature of the instance pointed to,
and it is the method of the B class which will be invoked.
So we will have a different message here,
when this last line of code is executed.
Here, we do indeed have polymorphic behavior on the part of the f method
since we invoked it outside of a constructor.
However here, the polymorphic aspect was completely ignored.
And this concludes our episode on virtual methods which are, in C++,
the basic building blocks for polymorphism.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
