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.
