Décrivez comment fonctionne le modificateur d'accès protected en Java, en quoi il se différencie des autres modificateurs, et quelles erreurs peuvent survenir en raison de sa mauvaise compréhension.

Réponse.

Le modificateur d'accès protected permet aux membres de la classe d'être visibles au sein du même paquet (package) et dans toutes les sous-classes (subclasses), même s'ils se trouvent dans d'autres paquets.

Différences avec d'autres modificateurs :

• private — accès uniquement dans la classe en cours
• default (sans modificateur) — uniquement accessible à l'intérieur du paquet actuel
• protected — accessible à l'intérieur du paquet actuel et dans les sous-classes en dehors du paquet
• public — accessible partout

Exemple :

package com.example.base;
public class Parent {
    protected void sayHello() {
        System.out.println("Hello from parent");
    }
}

package com.example.child;
import com.example.base.Parent;
public class Child extends Parent {
    public void tryHello() {
        sayHello(); // Accès autorisé !
    }
}

public class NotChild {
    public void fail(Parent p) {
        // p.sayHello(); // Erreur : accès interdit
    }
}

Question piégeuse.

Un classe externe (qui n'est pas enfant) peut-elle accéder à une méthode protected d'un autre paquet, ayant un objet de cette classe ?

Réponse : Non, l'accès aux méthodes protected d'un autre paquet est autorisé uniquement pour les classes héritées, et cela uniquement via this ou via une référence à un objet héritier, et non pas à un parent.

Parent p = new Child();
p.sayHello(); // Erreur !
((Child) p).sayHello(); // Succès (si appelé à l'intérieur de Child)

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.

---

Histoire

Dans un grand projet modulaire, un développeur a placé des méthodes métier importantes dans la section protected, pensant qu'elles étaient inaccessibles en dehors du paquet. D'autres développeurs ont accidentellement utilisé ces méthodes dans des tests dans le même paquet, et en raison du déplacement ultérieur des classes, des erreurs d'accès inattendues sont survenues.

---

Histoire

Dans un projet de microservices, une méthode avec un accès protected a été tentée d'être appelée par référence au type parent dans un autre paquet — l'appel n'a pas fonctionné. Cela a provoqué une défaillance dans certaines mécaniques d'extension du système, car l'on comptait sur une compréhension incorrecte de la portée.

---

Histoire

Dans une bibliothèque open-source, des champs protected ont été utilisés négligemment, ce qui les a rendus accessibles à un trop large éventail de classes, permettant ainsi de corrompre accidentellement l'état interne d'un objet, entraînant des problèmes dans des applications tierces.