Intérêt des classes imbriquées ?

Bonjour,

Quel est l'intérêt de créer une sous classe à une classe ?

Comme suit :

Code:

---

1 2 3 4 5 6

public class Toto {   public class Tata{   } }

---

Merci d'avance

http://www.javaworld.com/javaworld/javaqa/2000-03/02-qa-innerclass.html

Salut,


Je complète le lien en anglais de cymp par des exemples en francais :


Une inner-classe peut accéder à tous les éléments de la classe parente, même les protected et private (toutefois il est preférable de ne pas lier des champs private dans une inner-classe car cela implique la création de méthodes par le compilateur -- de plus ce n'est pas très 'propre').


Une inner-classe est toujours liée une instance de la classe parente avec X.this où X correspond au nom de la classe parente. De la même manière que le this, Le X.this n'est pas obligatoire s'il n'y a pas de conflit de nom.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public class Toto { protected String name;   public class Tata{ public void method() { // Ces deux lignes sont corrects : System.out.println(Toto.this.name); System.out.println(name); } } }

---

Ainsi on ne peut créer une instance de Tata qu'à partir d'une instance de Toto. Dans les méthodes de la classe Toto c'est automatique :

Code:

---

1 2 3 4 5 6

public class Toto { public Tata getTata() { return new Tata(); } ... }

---

Sinon il faut attacher manuellement l'instance :

Code:

---

1 2	Toto toto = new Toto(); Toto.Tata tata = toto.new Toto();

---

Mais cette approche est a éviter... (d'ailleurs la plupart du temps les inner-classes non-static ne sont pas public)



Les inner-classes anonymes sont très utile également afin d'éviter de créer une classe pour une simple méthode, tout en permettant d'accéder aux éléments de l'instance, et même aux éléments final de la méthode :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class Toto {   protected void longProcess(int count) { // traitement long }   public Runnable startLongProcess(final int count) {   return new Runnable() {   public void run() { longProcess(count); } } }   }

---

Il y a également les inner-classes static qui ne sont pas liées à une instance de la classe parente, mais qui peuvent quand même accéder à tous les éléments d'une instance de la classe parente :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class Toto {   protected String name;   public class TotoComparator implements java.util.Comparator { public int compare(Object o1, Object o2) { Toto t1 = (Toto) o1; Toto t2 = (Toto) o2;   return t1.name.compareTo(t2.name); } } }

---

Enfin cela permet aussi d'organiser le code d'une certaine manière (les inner-classes ont une relation forte avec la classe parente). De plus il est possible d'utiliser toutes les portée de visibilité (les classes 'standard' ne peuvent pas être déclaré en protected ni private)



Bien entendus ce n'est pas une raison pour en abuser ;)

a++

Pour poursuivre ce qu'a très bien expliqué adiGuba, j'utilise les "classes internes" pour mieux organiser mon code pour 2 raisons :

1 - une meilleure lisibilité, d'où une maintenance plus aisée quand il faut revenir sur un code vieux de plusieurs mois (ou années).

2 - Une meilleure architecture !

... car tu va pouvoir implémenter un listener à ta façon dans une classe interne et ajouter CE listener à un composant de ta classe parente. Cela évite de créer une classe "externe" qui n'est qu'un listener particulier adapté qu'à la classe parente.
L'architecture devient que chaque classe ayant besoin d'un "accessoire" (ecouteur, interfaces diverses, ...) possède son accèssoires dans sa propre classe.

Ce phénomène d'architecture "décomposée" devient même très utile pour les applications SWING, car quand tu commences à avoir 5 ou 6 conteneurs imbriqués, mieux vaut concevoir et séparer une fenetre en parties distinctes (des objets, donc des classes) regroupées au sein d'un même objet principal : la fenètre.

Voila qui peut t'écairer d'avantage sur l'intérêt.
:wink:
Régis.

Citation:

---

tu va pouvoir implémenter un listener à ta façon dans une classe interne et ajouter CE listener à un composant de ta classe parente. Cela évite de créer une classe "externe" qui n'est qu'un listener particulier adapté qu'à la classe parente.

---

Je suis d'accord avec toi sur ce point, c'est vrai que mettre une classe dans un fichier a part dans ce cas ne sert trop a rien

par cotnre :

Citation:

---

1 - une meilleure lisibilité, d'où une maintenance plus aisée quand il faut revenir sur un code vieux de plusieurs mois (ou années).

---

Quand on revient sur un code passé et que l'on a abusé des inner-classe, c'est trés vite lassant de rechercher ces dernieres, je suis vraiment pas sur qu'on y a gagne en lisibilité, je dirais même au contraire. Moi je conseillerai plutot de faire un fichier par classe car parfois ce n'est pas nous qui retouchons à nos classes :wink: sauf dans le cas cité précédement.

En fait, perso, j'utilise ca quand je dois avoir deux classes qui ont une interaction très forte entre elles, avec des actions en parralèles sur les deux, et que l'implémentation de Listener est assez lourde à faire parce qu'il y a 50 000 cas... On peut regrouper les deux classes en une, mais ca fait lourd, surtout si tu veux séparer le rôle de chacune.

Je l'ai fait notamment pour une generation de PDF en dynamique, via servlets...

J'avais une classe PDFServlet, qui faisait le lien avec l'utilisateur, et qui envoyait les flux, et récupérait les demandes, et une classe inetrne PDFTreatment, qui faisait la création du flux PDF, et qui donnait l'avancement...

Comme il y avait un reporting permanent sur l'etat d'avancement de la génération, les erreurs, etc... C'est effectivement assez efficace dans ce cas, et franchement lisible...