IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

Intérêt des classes imbriquées ?


Sujet :

Langage Java

  1. #1
    Expert éminent
    Avatar de elitost
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2003
    Messages
    1 985
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 985
    Points : 6 566
    Points
    6 566
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    public class Toto {
     
       public class Tata{
     
      }
    }
    Merci d'avance

  2. #2
    Futur Membre du Club
    Inscrit en
    Octobre 2005
    Messages
    24
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 24
    Points : 7
    Points
    7
    Par défaut
    http://www.javaworld.com/javaworld/javaqa/2000-03/02-qa-innerclass.html

  3. #3
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut Re: Intérêt des classes imbriquées ?
    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.thisX 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 :
    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();
    	}
    	...
    }
    Sinon il faut attacher manuellement l'instance :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : 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++

  4. #4
    Membre averti
    Inscrit en
    Avril 2004
    Messages
    503
    Détails du profil
    Informations forums :
    Inscription : Avril 2004
    Messages : 503
    Points : 445
    Points
    445
    Par défaut
    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/

  5. #5
    Membre confirmé Avatar de Scorpyosis
    Homme Profil pro
    Inscrit en
    Janvier 2004
    Messages
    365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2004
    Messages : 365
    Points : 570
    Points
    570
    Par défaut
    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 :

    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 sauf dans le cas cité précédement.
    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

  6. #6
    Membre actif
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 220
    Points : 266
    Points
    266
    Par défaut
    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...

Discussions similaires

  1. [C#]Remonter des événements dans des classes imbriquées
    Par Kcirtap dans le forum Windows Forms
    Réponses: 9
    Dernier message: 14/12/2013, 13h43
  2. ecrire une methode aves des classes imbriquées
    Par artemis93 dans le forum Débuter avec Java
    Réponses: 8
    Dernier message: 07/06/2011, 01h18
  3. [interface] Manager des class imbriquées
    Par Monkey56 dans le forum C#
    Réponses: 4
    Dernier message: 14/04/2011, 11h15
  4. L'intérêt des classes abstraites face au interfaces
    Par diopahmadou dans le forum Langage
    Réponses: 2
    Dernier message: 07/12/2009, 11h43
  5. Réponses: 2
    Dernier message: 15/03/2007, 15h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo