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.
Masquage, substitution et surcharge
Loading...
Del curso dictado por École Polytechnique Fédérale de Lausanne
Introduction à la programmation orientée objet (en C++)
198 calificaciones
École Polytechnique Fédérale de Lausanne
198 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
During our learning,
we encountered three different concepts
Function or method overloading;
shadowing;
qu'on appelle en anglais shadowing
and overriding
of virtual methods.
The latter applies only to virtual methods.
So for virtual methods, we could in principle have all three:
overloading, shadowing and substitution.
What are these exactly?
To avoid confusion for some programmers, since C++2011,
we have two new keywords which I will talk about at the end of this episode,
namely <i>override</i> and <i>final</i> which allow the programmer to specify his intention.
Let's go over these three concepts in detail to clear up
what they do.
Before illustrating these concepts with an example, let's review their definitions.
Function or method overloading happens when a function or method
has the same name as another, but has different parameters,
and has the same scope.
Careful, in C++, overloading is only possible within the same scope.
We will come back to this later.
Shadowing, or hiding, occurs when entities, variables, functions
or in the case of object-oriented programming, members and methods,
have the same name but different scopes.
Thus, following scoping rules,
C++ resolves to the nearest scope,
that is, the closest scope hides
the entity with a further scope.
Note that a single method with the same name is enough to shadow all other methods
of further scope, independently of their parameters
since with regards to parameters,
we would be in the case of an overload,
and overloading only happens within one scope.
So if we are in another scope, we simply need to have the same name
to mask all other methods. We will come back to this with an example.
Finally, overriding is valid only
for virtual methods, and the idea is to redefine, in a subclass,
a virtual method inherited from a superclass
allowing what is known as
dynaming binding, and polymorphism.
The method of the actual instance will be invoked if it is called
via a pointer or a reference and, similarly to shadowing,
if we redefine only one virtual method,
it will override all the others,
even if they don't have the same parameters.
Only one will be defined, but it will simply hide the others.
The rules of shadowing also apply to overridden functions.
Let's review this in detail in an example:
Imagine that we have three classes A, B and C
such that B and C both inherit from A.
These three classes will have a method <i>m1</i> which
we will overload, override and shadow.
To make the example a bit more concrete,
in the main function, we have an instance b of class B
and an instance c of class C.
We will go over the different ways of calling these m1 methods.
In class A, we have a first m1 method which takes an integer.
Each of these methods will simply display
a message indicating which method was called.
Moreover, in A, we also have an m1 method which has a different list of parameters
than the first method.
Here, it takes a string instead of an integer.
These two m1 methods have the same scope, the scope of class A.
They have different lists of parameters, but the same name.
This is therefore a simple case of overloading.
In class B, we have an override of one of the two methods.
We override the method which takes a string
as argument.
This m1 method overridden here in the B subclass of A
thus hides A's m1 method in B.
Since it is the only method of the two which was overridden in B,
based on rules of scope and shadowing,
this method also masks the other method since in class B,
we will only have one accessible m1 method.
Class B will effectively have three m1 methods.
Its own m1 method and the two m1 methods inherited from the superclass, A.
But because of scope resolution rules,
when we are in B, we resolve to the closest scope,
and the only one directly accessible is the one that was
defined in B, which thus hides both of A's methods.
Let's look at this in the main.
Here, we have our instance b. We cannot make a call like this.
This is why we commented the m1 method that takes an integer
since the m1 method taking an integer, inherited from A,
is hidden by the method in B which takes a string.
We can indeed call the m1 method
which takes a string. This poses no problem at all.
But we cannot call the method from m1 taking an integer.
We get a message saying that this function cannot be called.
However, it does exist; if we want to call it, we will have to use
the scope resolution operator
saying "the method m1 of scope of class A which belongs
to the instance b of subclass B".
which does indeed inherit this method from class A since B is an A.
This method can thus be called here
but it will need to be "unhidden" using the scope resolution operator.
In class C, we have introduced a third method
a new method, since we have a third type of parameter
with a double. This will define a new, third m1 method
which will, once again, following scoping rules,
hide both of the methods inherited from A.
With the instance c of class C, we can call neither
the method with the string
nor the method with the integer.
Careful, this is a trap. This call here, c.m1(2) does not invoke
the method taking an integer since it is hidden.
If you execute this code, you will get a message
saying "C::m1(double)" as it is indeed the only method
which can be called directly without unhiding in C's scope.
And an integer can be converted to a double,
so here, there is a conversion from an integer to a double to call
the only method which is in C.
Of course, as before, we can unhide
the methods taking a string or an integer.
By using the scope resolution operator, c.A::m1 with a string,
we will of course call A's method, which takes a string.
This call here, with an integer, will now unhide A's m1 method
inherited by the subclass C;
we will call this method here.
That's it for the aspects of overloading and shadowing,
let's now discuss the overriding aspect.
In fact, all of these methods were declared as virtual.
We simply need to declare, here, these methods as virtual
to make them virtual automatically in the subclasses.
Here, since we have exactly the same method, the <i>virtual</i> is transitive.
It doesn't have to be repeated.
However here, we have a new method.
So we can define it as virtual or not.
All of these methods are declared as virtual,
so we will have an override.
Overriding follows the same rules as shadowing.
Essentially, dynamic binding will be used
if we have pointers or references,
which was not the case here.
Here, we simply had instances.
To observe the effects of overriding and dynamic binding,
we will need to use pointers.
This is what we do in this new example.
We still have the instances b and c of classes
B and C, respectively,
but we now have a pointer-to-A that we name pa.
First, pa will point to b
and then it will point to c.
Here, we make pa point to b.
The memory situation is as follows.
pa points to b and we call the m1 method
through this pa pointer.
Note that m1 is a virtual method
which is overridden in class B.
So polymorphism is taken into account here.
The m1 method from class B will indeed be called
and will output the message "B::m1(string)".
However, even though pa points to a B, it is still a pointer-to-A.
And remember that in C++, it is the type that
is determining when there is no polymorphism;
static binding is used.
We resolve according to the type.
So here, pa is a pointer-to-A and as such,
can access A's methods.
These method calls are in class A.
In other words, these calls are in the scope of A and so
we can absolutely call the m1 method with an integer,
even though pa points to a B.
We are in A's scope.
So here, it is A's method which will be called: "A::m1(int)".
Similarly, even if pa points to c, even though we point to a C,
we are still in the scope of A
since we are working with a pointer-to-A.
Here, we will call the method.
Careful, even if we pass a double, we are still in A's scope
and so we will call the method that takes an integer here.
This double will be converted to an integer to call, within the scope of A,
the only method that can be called with a double.
It is this one, where we convert the double to an integer.
This is quite possible in C++ and it is indeed
this method which will be called.
The method that is in C is not accessible in the scope of A.
Though a C is an A, an A is definitely not a C.
Here, since we are in A's scope, it is in this scope that
we will resolve the name "m1".
So it is indeed m1 with an int which will be called and
we will get the output for A::m1 with an int.
For the same reasons, we absolutely cannot try
to unhide the method taking a double by trying to use
the scope resolution operator on C.
This is completely illegal since we are passing through a pointer-to-A
and an A is not a C.
C is an A but A is not a C.
A is at the top of the hierarchy.
C is an A, but A is definitely not a C.
So this would not compile. It is forbidden by the compiler.
It is not A which inherits from C, but C which inherits from A.
There! All of this is certainly rather technical
and at first may be a little difficult.
You should come back to this episode later, once you have
had some practice with polymorphism and its different aspects:
shadowing, overriding, and especially overloading
the latter of which should not pose any more problems.
Actually, since these concepts are quite complicated,
C++ 2011 introduced two new keywords
to allow the programmer, if he so wishes,
to clarify his intentions.
These keywords are <i>override</i> which indicates that we want
to override a virtual method inherited from a superclass;
and <i>final</i> which prevents any future override
of the associated method in potential future subclasses.
Let's look at this in detail in an example.
Suppose that here, we have a class A which contains four methods:
a method f1 that is simply defined as virtual;
a method f2 which is also virtual and has the const qualifier,
which cannot modify the instance; a method f3, which is not virtual;
and an f4 method on which we add the final qualifier.
Then we have a class B which inherits from A and will, of course,
override and shadow these various methods.
So we have an override of method f1 in class B.
The prototypes are identical.
So the <i>override</i> keyword is used correctly.
Indeed, f1 is an override of this method.
Here, we have another method.
I will let you guess what it is.
Here, you can see that we have a typo.
The developer wrote f-lowercase L instead of "f1".
This, I guarantee, is a rather difficult error to find while debugging.
Such a small difference between a lowercase L and a 1
is often hard to spot.
So here, if we had forgotten the <i>override</i> keyword...
-- of course without this line here --
what the person who wrote this in class B wanted would have been to override the method f1
But instead of overriding the f1 method, because of this typo,
they would have introduced a new virtual method in B.
What the <i>override</i> keyword allows
is to have the compiler check for this.
As the developer of this class B has specified,
they want an override of one of A's methods.
In this case, since there is no fl method in A,
the compiler will indicate that there is an error.
This fl method does not override any method from A.
This protects class B's developer
against potential mistakes.
Another type of mistake can be seen on the f2 method.
Class B's developer wants to override the f2 method.
However here, we will get a compilation error.
Can you see why?
The error here is that the f2 method is not const
whereas it was defined as const in class A.
So the f2 method here is a different f2 method
Be careful! const is completely part of the specificity
of the method header.
The full prototype of the method contains const and so here,
this is a different f2 method.
So the compiler doesn't accept this.
This is not an override of the f2 method
but a new f2 method.
So this is another example of a protection against developers' mistakes.
Forgetting the const keyword, or making a typo.
Regarding the f3 method, this could be a conception mistake
at A's level.
Maybe f3 should have been virtual and we thought that
we could override this f3 method.
Remember that it is unnecessary to repeat the virtual keyword.
We could easily, even for a virtual method, write this.
The developer of class B wants to override a virtual method,
so they add the override keyword.
Here again, they get an error message from the compiler saying:
"No, careful, you are not doing what you think you are doing".
This f3 method cannot be overridden because
it is not a virtual method.
So here we have pure shadowing without an override.
Here is a third case that can protect the developer
of class B against potential errors.
Here, the error would come either from his interpretation of what class A is
or even from the developer of class A who may have forgotten the virtual keyword.
Finally, the last situation with the final keyword.
Here, class A's programmer prevents any future override
of this f4 method.
So the developer of class B, a subclass of A, cannot
override the f4 method.
It is <i>final</i> here, meaning that we cannot override
this f4 method in subclasses.
So the compiler would refuse to compile this line.
That's it for this example.
We recommend that you use the override keyword.
Even if it a little cumbersome to write.
Use it to protect, at first,
against potential errors such as the ones we have just discussed.
Concerning the final keyword, I don't think it is essential at this course's level,
you can forget about it. In my opinion, it is completely useless.
Why would we want to prevent anyone from overriding these methods?
Finally, to be exhaustive, I would like to mention
that the final keyword can also be used to prevent deriving subclasses.
That is, to prevent inheriting from a class.
For example, we could define a Sterile class here
which cannot have any subclass.
By adding the final keyword here.
So we would not be able to inherit from this Sterile class here.
This keyword makes the compiler signal an error
whenever a subclass tries to inherit from this superclass.
Here again, I don't think this is very interesting at this course's level.
For this course, you can forget about final
But do make sure to write override each time
that you want to override a virtual method inherited from a superclass.
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.
© 2019 Coursera Inc. Todos los derechos reservados.
