Ce cours introduit la programmation orientée objet (encapsulation, abstration, héritage, polymorphisme) en l'illustrant en langage Java. 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 Java) ». 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.
Héritage : droit d'accès protected
Loading...
Из курса от партнера École Polytechnique Fédérale de Lausanne
Introduction à la programmation orientée objet (en Java)
145 оценки
École Polytechnique Fédérale de Lausanne
145 оценки
Из урока
Héritage
Cette semaine nous abordons deux notions fondamentales de la programmation orientée objet : l'héritage et le polymorphisme.
Познакомьтесь с преподавателями
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
In this video
we will continue the topic of inheritance
and will consider in this context
the notion of protected access rights.
You have seen that the accessibility of a class's member
--a data member or a method--
can either be "public" which means
that it can be used without restriction
whether inside or outside a class,
or it can be private, which means that the member
can only be directly accessed inside the class.
In Java, there is also the access right "by default"
if no access modifier is specified
in front of the member's declaration
and in this case, the member is visible
from any class in the same package.
This is also the case for the default package
that you have frequently used
in the excercizes.
Note, that we have prepared a PDF complement on packages
that is available on the course's website.
The question that we ask now is
what about access rights in a hierarchy of classes?
Suppose that we have a superclass A
from which is derived a subclass B.
Suppose that the superclass
includes the declaration of a data member "a"
that is private.
Since we have always
declared variables private up to now,
our question is:
"Is this data member accessible
in a method of the class B?"
For example, could we write something like this
in the class B?
We have seen that due to inheritance,
the subclass B has
a data member "a" inherited from A,
but the question is, "Can B use "a" freely,
and use it directly in its own methods?"
However, as we saw, the private access modifier
only insures the visiblity inside the class
in which the member is defined.
Which means that "a" can only be used here directly
in the methods of the class A.
Which then means that this is not allowed.
So we find paradoxically
that the class B inherits from A and has at its disposal
a member variable "a"
but cannot use it freely,
accessing it directly
like here in this case.
Because it is perhaps intuitive
that a subclass has at its disposal directly all of its data members
defined in the class itself
but also those inherited from a superclass,
there exists another access right
which is "protected".
When a member is declared "protected" in a given class
it is consequently accessible directly from
any class of its descendants.
The access right "protected" in Java
is specified with the keyword "protected".
So, replacing "private" with "protected"
in this case,
renders this syntax valid.
Note that a protected access enables a member to be seen
in other classes of the package
containing the class with the protected member.
Schematically, here is how this can be summarized,
so suppose that we have a protected member
in a class defined in a certain package
then this protected member is directly accessible
in all the classes descendant from A
whether they are in the same package or not
which means that in all the classes derived from A,
this access is possible.
And what if there isn't any dependency?
Well, in Java, a protected member is also accessible
in all the classes in the same package
as the class containing the protected member
even if they are not linked by inheritance.
For example, the class C, doesn't have any relationship
with the class A, but it is in the same package,
hence a method from C
can directly access a protected data member of A
through any instance of A,
without having to use another method.
This access is possible.
On the other hand, a class in another package,
and does not have an inheritance relationship
with the class in which the protected member is
can not access the protected data members.
Here, for example, the class E cannot access
the protected member "a" through an instance of A.
The access modifier "protected" is dangerous for encapsulation
namely in that it allows
all programmers of extensions of the class A,
so all programmers with classes that inherit from A
to access protected members as if they were public
which results in strong dependencies between
because the programmer of the class A
cannot freely modify the class's implementation details
for the protected members
without the programmer of class D being disturbed.
The default access right
in which case no access modifier is specified in front of the
member's declaration,
is more restrictive
than being private
in a package other than the default package
to the effect that this kind of access is invalid.
With a default access, members can only be
accessed in the classes of the same package.
The default access
even though it is more restrictive than protected access
hinders a good encapsulation
because it enables an open access
from all classes of a package.
To summarize this discussion,
a subclass cannot access private members
inherited from superclasses,
and to use them
even if through inheritance the subclass has them
it has to use getters or setters
provided in the superclass.
If a superclass wants to give access to a member to its subclasses,
then it can declare it protected.
But be careful, this interferes with a good encapsulation.
In one word, protected member variables are not recommended.
Finally, to understand the access modifier protected,
you have to grasp that it is an extension of
of the private sphere when we are outside of subclasses
and outside of the same package.
So to take a concrete example,
let's examine again the hierarchy of characters
with a subclass Guerrier
derived from a superclass Personnage.
So imagine that the class Personnage
was defined in a certain package
"P1" for example.
Whichever package it is defined in,
the subclass Guerrier, due to inheritance,
will be able to directly access the protected members
in the methods of
the class Guerrier,
which is in the class Personnage,
and directly use this protected member variable.
On the other hand, if I am in another package,
for example the package P2,
and in a class without any parental link
with the class Personnage,
for example, a class Jeu,
which uses in its principal program,
a few characters in the hierarchy,
such as in the main method
declaring an instance of Guerrier,
in this case, the data member energie cannot be accessed
in the method main
with an instance of Guerrier.
For classes not linked by inheritance,
with the superclass Personnage
and that are not in the same package,
for them, it is as if the protected data member was private.
To recap on access rights,
so public members are accessible without restriction
by all users of
the class in which they were defined,
protected members are intended for users who extend the class,
by inheritance or who work in the same package
but can hinder inhibit good encapsulation,
and finally, private members are reserved for the class programmers
which reflect the internal structure of the class
and cannot be modified without disturbing
the class users or users that extend the class.
So this concludes this episode
on access rights in a class hierarchy.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
