Réponse.

Les interfaces imbriquées (inner interfaces) sont des interfaces déclarées à l'intérieur d'autres classes ou interfaces. Elles sont apparues pour la première fois dans le langage afin de structurer de grandes classes et de cacher les détails de l'implémentation. Cette encapsulation permet de grouper logiquement des contrats, améliorant ainsi considérablement la lisibilité et la maintenance du code.

Historique de la question

Depuis les premières versions de Java, il est possible de déclarer des interfaces imbriquées statiques et non statiques à l'intérieur de classes et d'autres interfaces. Cette pratique s'est répandue dans de grandes bibliothèques (par exemple, dans les collections Java).

Problème

Une mauvaise compréhension de la visibilité et de la portée des interfaces imbriquées conduit souvent à des erreurs de conception d'API et complique l'architecture de l'application. Elles ne peuvent pas être utilisées comme des membres d'instance, elles sont toujours statiques par nature.

Solution

Les interfaces imbriquées sont utilisées pour donner une structure plus modulaire et pour mettre en évidence des contrats spécifiques liés uniquement à la classe d'enveloppe. Par exemple, l'interface Entry à l'intérieur de Map :

public interface Map<K, V> {
    interface Entry<K, V> {
        K getKey();
        V getValue();
    }
    Set<Entry<K, V>> entrySet();
}

Caractéristiques clés :

L'interface imbriquée est toujours statique (non liée à une instance de la classe externe).
Permet de limiter la portée et la responsabilité de l'interface.
Utilisée pour grouper des fonctionnalités uniquement liées à la classe/interface externe.

Questions pièges.

Question 1 : Peut-on créer une instance d'une interface imbriquée sans avoir une instance de la classe externe ?

Oui, une instance d'une interface imbriquée peut être implémentée séparément, sans créer d'objet externe, puisque l'interface est imbriquée statiquement.

Question 2 : Quelle est la portée de l'interface imbriquée à l'intérieur de la classe ?

La portée est régulée par des modificateurs (public, protected, private, package-private). Cependant, on les rend souvent publiques si un accès extérieur est nécessaire.

Question 3 : Une interface imbriquée peut-elle contenir des interfaces imbriquées ?

Oui, toute profondeur d'imbrication des interfaces est autorisée, bien que cela soit rarement pratiqué en raison de la diminution de la lisibilité.

Erreurs typiques et anti-patrons

Définir une interface imbriquée comme non statique.
Violations du principe de responsabilité unique, en surchargeant les classes externes avec un nombre excessif d'interfaces imbriquées.
Encombrement de la hiérarchie, rendant la maintenance difficile.

Exemple de la vie réelle

Cas négatif

Dans un grand projet, 10+ interfaces imbriquées ont été définies à l'intérieur de la classe Service. Le nombre de liaisons augmentait, rendant la navigation et la compréhension du code plus difficiles.

Avantages :

Toute la logique est visible dans une seule classe.

Inconvénients :

Mauvaise lisibilité et maintenabilité.
Augmentation du nombre d'erreurs lors de modifications.

Cas positif

Dans la classe DataProcessor, une interface imbriquée Validator a été définie, qui n'a été implémentée qu'à l'intérieur de DataProcessor et nulle part ailleurs.