Bonjour,
Quel est l'intérêt de créer une sous classe à une classe ?
Comme suit :
Merci d'avance
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 public class Toto { public class Tata{ } }
Bonjour,
Quel est l'intérêt de créer une sous classe à une classe ?
Comme suit :
Merci d'avance
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 public class Toto { public class Tata{ } }
Cordialement,
elitost(Eric Reboisson)
SpringSource Certified Spring Professional
Certifié SCWCD J2EE 5.0
Certifié SCJP J2SE 5.0
Certifié ITIL Foundation
Responsable : FAQ Maven 2 , FAQ SCM
Autres : Site web Developpez , Mon site personnel , Mon CV
Twitter : Suivez moi sur Twitter
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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 :
Sinon il faut attacher manuellement l'instance :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 public class Toto { public Tata getTata() { return new Tata(); } ... }
Mais cette approche est a éviter... (d'ailleurs la plupart du temps les inner-classes non-static ne sont pas public)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Toto toto = new Toto(); Toto.Tata tata = toto.new Toto();
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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.
Régis.
L'interêt du doute est que cela fait avancer.
(parenthèses)Je suis à la recherche d'un emploi sur Valence(26) et ses environs.
mon cv:
http://charegis.netcv.org/
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 rientu 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.
par cotnre :
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 sauf dans le cas cité précédement.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).
Les deux principales inventions sorties de Berkeley sont UNIX et le LSD. Difficile de croire à une quelconque coïncidence - Jeremy S. Anderson
Avant de vouloir qu’un logiciel soit réutilisable, il faudrait d’abord qu’il ait été utilisable - Ralph Johnson
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...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager