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.
Collections hétérogènes
Loading...
Del curso dictado por École Polytechnique Fédérale de Lausanne
Introduction à la programmation orientée objet (en C++)
178 calificaciones
École Polytechnique Fédérale de Lausanne
178 calificaciones
De la lección
Polymorphisme
Cette semaine nous abordons la quatrième et dernière notion fondamentale de la programmation orienté objet : le polymorphisme.
Conoce a los instructores
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
In this episode, we will go over the details of
one of the important applications of polymorphism, known as
"heterogeneous containers"
Up to now, we have seen that inheritance and virtual methods allow us
to define generic functions accessible to all instances of a class hierarchy
This is polymorphism.
We learned that if we want to use functions or methods
in a polymorphic way,
that is, apply these functions to objects in a polymorphic way,
then these objects must be passed by reference.
What if we have a set of objects, a collection of objects (a.k.a. an "container")
belonging to a hierarchy which we wish to be able to manipulate
in a polymorphic way?
This is known as a "heterogeneous container".
Meaning that each object stored in the container, in the set
can have slightly different, specific behavior.
Let's illustrate this with the example of our game with the characters.
We had a Personnage class with a certain number of members
and specific methods, and different subclasses:
thieves, magicians, warriors etc, who were all characters.
We wanted to put them in a game that would contain several characters.
So we would have a collection of characters, but we want each
character to behave according to their real nature.
A warrior will behave as a warrior, a thief as a thief, etc.
So this collection will be "heterogeneous".
How do we define the game in this case?
We could define the game like this, of course:
having a specific container for each of the subclasses, that is,
having a container for all of the warriors
one for the magicians, etc.
Then we could display all of the warriors through a method
allowing to display the warriors,
display all the magicians through another specific method, etc.
We could add a warrior to the game,
or add a magician, a thief, etc.
This solution is possible and in some cases,
it will be necessary to differentiate between the subclasses
and to have specific containers for each of the subclasses.
They will not be heterogeneous containers.
There would be as many specific containers as subclasses.
That solution is quite possible, but we could imagine
a different solution.
It depends on the context, on the needs of the program,
where we could imagine managing all the characters in a global way,
to manage them generically in a container of characters.
These characters would have their own specificities,
so we would have a heterogeneous container.
In that case, we would define the "Jeu" class like this
We would have a collection of characters, in the form of a vector
which would group all our characters.
We would only have one "afficher" method
that would display all of the characters.
And we would have a generic method here, "ajouter_personnage" which would allow us
to add a generic character to the collection.
In this context, we would want each of the characters to have
their own behavior and so if "personnage[i]" is a warrior,
then the method "personnage[i].afficher" would call the afficher method of the
warrior subclass.
We would want to have a polymorphic behavior
for the characters stored in the game.
Unfortunately, the code we have present up til now does not allow
polymorphic behavior. Indeed, here we have
a vector of characters and we access the characters
directly without passing through a reference or a pointer.
However, remember that polymorphic behavior is only possible
with virtual methods, as well as
either pointers or references.
Which one should we use here?
I'll remind you of a general piece of advice concerning pointers and references:
Use references whenever you can,
and pointers when you must.
Here, the idea would be to use a set of references.
Unfortunately, we cannot put references in a vector
nor in any standard C++ container.
The technical reasons for this are beyond the scope of this course.
We are forced to use pointers here.
So we will change the implementation of our Jeu class to have
a vector of pointers to characters.
To have polymorphic behavior for our characters, we will have
an vector of pointers-to-Personnage.
The question we could ask ourselves here is, do we want to use
"C-style" pointers or "smart pointers", C++11 pointers?
So here is an alternative, a C++11 version.
We recommend you use this second approach.
We will detail the reasons for this choice in a extra, optional episode
which will follow this episode.
If you follow our su"ggestion and use "smart pointers
in the C++11 style, you will define a vector of unique pointers to Personnage.
To use unique pointers, remember to include
the <i>memory</i> library.
For those who would like reminders on pointers, we have uploaded
all of the courses that we gave on pointers
from our previous MOOC, Introduction to Programming.
I encourage you to
review these courses if necessary.
So here, we could use either solution.
In any case, note that it is pointers that
will be stored in this container.
The "personnage" vector here is a vector of pointers, and no longer
of instances directly. This will have some influence
on the design and execution of the game, since the instances
are now outside of the Jeu instance.
In Jeu, we only have pointers to the instances.
How do we continue developing our Jeu class and adding
these methods for displaying or adding characters, for example?
The easiest is to first look at how we will use this game, this instance of Jeu.
So, we would declare a game, an instance of Jeu, and imagine that
we want to add a character.
But we have to add a pointer. The easiest is to add a pointer
allocated dynamically with a "new". For example here, we create a new warrior,
"new Guerrier", which will return a new pointer to a warrior.
So in memory, we would have the following situation:
a <i>Jeu</i> which has a set of pointers.
At first, it is completely empty.
Then, we create a warrior in memory
and the "new" would return a pointer to this warrior that we would store
in our container.
So the prototypes for our methods would be:
here, a "ajouter_personnage" (TN: means "add_character") method that would
take a pointer to Personnage.
This is what it receives, as new returns a C-style pointer to a Personnage.
Then the afficher method which doesn't pose any problems,
which displays all the characters.
So we would have the usual prototype for this display method.
Now, let's see how we can define these methods.
Let's start with the method that adds a character.
Its prototype takes a C-style pointer to a character
to allow a call as we have just seen.
We start, to be safe, by checking that we have indeed received, through
the "nouveau" (TN: means "new") pointer here
a pointer to a real Personnage instance.
So we check that the pointer is not null.
Then we add it to the character container.
Remember that we decided to
implement the character container as a vector of
unique_ptr's to Personnage.
So we simply add it with a "push_back"
The C-style pointer, "nouveau", returned by the call to "new"
will be transformed to a unique_ptr.
Because new returns a C-style pointer and we have decided to
implement our pointers as C++11-style "smart pointers",
we will transform this C-style pointer here into a unique_ptr.
Let's go over the previous call in detail,
" jeu.ajouter_personnage (new Guerrier) ". (TN: means "game.add_character(new Warrior);")
We call the constructor with parameters
for Guerrier's constructor. It will do the following:
first, it will execute new Guerrier, which will create a new warrior
in memory.
New will return a pointer to this allocated memory area.
This pointer will be passed to the ajouter_personnage method
and be called "nouveau".
This pointer is not null.
So we arrive here
in the Jeu class and do a push_back.
Suppose that this vector was initially empty.
So we execute this push_back which will add an element to our vector
in which we will add the result of the transformation of this C-style pointer
to a unique_ptr pointing to the memory area allocated by the new statement.
Now, let's talk about the "afficher" method.
Suppose that each character has its own afficher method
which is polymorphic.
So we simply need to do this, to loop over all of the characters stored
in the vector of pointers to characters,
and to call the afficher method
through this pointer. This is exactly why we have pointers,
to have a polymorphic behavior.
However, this code does not compile.
Indeed, our "Personnages" collection is a vector of
unique_ptrs, of unique pointers.
There cannot be more than one pointer to a given memory area.
In memory, we have something like this:
a vector of unique_ptrs pointing to characters.
When we write the for loop,
when we write the for loop like this, it happens the the "quidam" variable
is another variable that will
take the value of each of the elements of the personnages vector, one after the other.
So quidam is a pointer that will point to the same area
as the various pointers to our characters, one after the other,
as they are stored in the vector.
So for example, the first step, which is to say that quidam equals this pointer,
means that two pointers are equal, they point to the same area.
This is impossible, due to the fact that we have unique_ptrs here.
We can only have one pointer per memory area.
So this solution is unacceptable.
To do this, we need a reference to the stored objects,
a reference to the unique pointers. That is quite possible.
So the correct for loop is written like this:
"for auto reference", of course here we will not modify anything,
as the display method is const, so we can use a "const reference".
So "for auto const reference"; quidam is now
a constant reference to the elements of the personnages vector.
That is, a constant reference to unique_ptrs.
This is a subtlety of unique pointers.
Now, let's see how we can use our Jeu class.
Here, we would declare a game and add characters to it
by calling the ajouter_personnage method and creating them dynamically with new.
We have a new warrior here, with parameters for its constructor.
Then we add a new magician, a new thief,
perhaps another new warrior, etc.
When we want to display the game, we simply call jeu.afficher.
But this innocent Jeu class nevertheless hides a potential danger.
What happens if one of the objects we added to the collection,
-- or rather, whose address we added to the collection -- what if one of these objects
were to disappear?
In that case, we would still have a pointer to that object in the vector
despite this object being destroyed, and this could cause big problems.
For everything to work correctly, it is absolutely necessary
for all of the elements that are pointed to to last at least as long as their pointers.
So in this example, all of the characters in the game must exist
at least as long as the game.
And it is up to the programmer to ensure that with good design.
So, it is up to the programmer not to make this kind of mistakes.
For example, imagine a slightly naive programmer who wants to create a function
to create and add a magician into the game
This function would modify the game, and take a reference to the game
and it would create a magician here,
passing parameters to its constructor and then,
it would call the ajouter_personnage. And since we must pass pointers
to add characters,
it passes the address of this magician here
And so in the main, we would have the game.
We call this "creer_magician" function.
We pass the game by reference to add a magician to it.
Then we display the game
The problem is that this creer_magicien function adds
a new magician which is a local variable.
It is important never to do this sort of thing,
never to add local variables.
This local variable will cease to exit: "mago" here will cease to exist as soon as
we exit the function.
So here, we will have added a pointer to a magician via
a reference, but this magician will no longer exist
as soon as we exit the function that created it.
So, from this semicolon here, we should never try to access
this magician.
We should not try to display it anymore.
So here, we know what will happen, we will display a magician
that potentially does not exist anymore.
I say potentially because on some machines,
as this code is relatively short, nothing bad may actually happen.
But if you imagine several lines of code with several manipulations
between this function call and this display here,
then it is virtually certain that you will get a nonsense result.
So, never do such a thing!
Never take the address of a local variable,
never use the address of a local variable like this
The correct way to do this, to solve this sort of problem is to use
what is called dynamic allocation and to guarantee that the allocated memory area
will be preserved for at least as long as its container.
So for example, here, the creer_magicien method which takes a game by
reference, would add to this game a dynamically-allocated magician
as we have done up til now. This new will trigger a dynamic allocation
and the memory area will exist as long as we don't call delete.
In the case of a container where we manage pointers through unique_ptrs,
we don't even need to call delete. The memory will be freed automatically
by the unique_ptr as soon as it is no longer used.
This is one of the advantages of unique pointers.
This is why we recommend you use
these "smart pointers", these unique pointers at first.
You will not need to bother about
freeing memory, so you will not risk accidentally freeing memory while
it is being used. However, the pointer
will automatically be freed as soon as we no longer use this memory area.
Now, the second aspect, the unique aspect.
The smart aspect of the pointer handles deallocation,
and the unique aspect prevents having multiple references to the same area.
As we saw in the example of the for loop, this introduces a few constraints.
But it is a big advantage to have only one pointer to a certain
object. That way, the object truly belongs
to the container to which it is supposed to belong.
There are no other places in the program pointing to this object
and that could modify it.
These are the reasons why we recommend you use, at first,
unique_ptrs
Now, we could also use C-style pointers.
If you wish to learn about this, we have produced another episode,
an optional one, which will detail this solution
and should thus shed more light on the advantages of unique_ptrs.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
