IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Penser en Java 2nde édition - Sommaire |  Préface |  Avant-propos | Chapitre : 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 |  Annexe : A B C D  | Tables des matières - Thinking in Java

  Chapitre 8 - Interfaces et classes internes

pages : 1 2 3 4 5 6 

Dans Parcel3, de nouvelles particularités ont été ajoutées : la classe interne PContents est private afin que seule Parcel3 puisse y accéder. PDestination est protected, afin que seules Parcel3, les classes du packages de Parcel3 (puisque protected fournit aussi un accès package - c'est à dire que protected est « amical »), et les héritiers de Parcel3 puissent accéder à PDestination. Cela signifie que le programmeur client n'a qu'une connaissance et des accès restreints à ces membres. En fait, on ne peut faire de transtypage descendant vers une classe interne private (ou une classe interne protected à moins d'être un héritier), parce qu'on ne peut accéder à son nom, comme on peut le voir dans la classe Test. La classe interne private fournit donc un moyen pour le concepteur de la classe d'interdire tout code testant le type et de cacher complètement les détails de l'implémentation. De plus, l'extension d'une interface est inutile du point de vue du programmeur client puisqu'il ne peut accéder à aucune méthode additionnelle ne faisant pas partie de l'interface public de la classe. Cela permet aussi au compilateur Java de générer du code plus efficace.

Les classes normales (non internes) ne peuvent être déclarées private ou protected - uniquement public ou « amicales ».

Classes internes définies dans des méthodes et autres portées

Ce qu'on a pu voir jusqu'à présent constitue l'utilisation typique des classes internes. En général, le code impliquant des classes internes que vous serez amené à lire et à écrire ne mettra en oeuvre que des classes internes « régulières », et sera simple à comprendre. Cependant, le support des classes internes est relativement complet et il existe de nombreuses autres manières, plus obscures, de les utiliser si on le souhaite : les classes internes peuvent être créées à l'intérieur d'une méthode ou même d'une portée arbitraire. Deux raisons possibles à cela :

  1. Comme montré précédemment, on implémente une interface d'un certain type afin de pouvoir créer et renvoyer une référence.
  2. On résoud un problème compliqué pour lequel la création d'une classe aiderait grandement, mais on ne veut pas la rendre publiquement accessible.

Dans les exemples suivants, le code précédent est modifié afin d'utiliser :

  1. Une classe définie dans une méthode
  2. Une classe définie dans une portée à l'intérieur d'une méthode
  3. Une classe anonyme implémentant une interface
  4. Une classe anonyme étendant une classe qui dispose d'un constructeur autre que le constructeur par défaut
  5. Une classe anonyme réalisant des initialisations de champs
  6. Une classe anonyme qui se construit en initialisant des instances (les classes internes anonymes ne peuvent avoir de constructeurs)

Bien que ce soit une classe ordinaire avec une implémentation, Wrapping est aussi utilisée comme une « interface » commune pour ses classes dérivées :

//: c08:Wrapping.java
public class Wrapping {
  private int i;
  public Wrapping(int x) { i = x; }
  public int value() { return i; }
} ///:~

Notez que Wrapping dispose d'un constructeur requérant un argument, afin de rendre les choses un peu plus intéressantes.

Le premier exemple montre la création d'une classe entière dans la portée d'une méthode (au lieu de la portée d'une autre classe) :

//: c08:Parcel4.java
// Définition d'une classe à l'intérieur d'une méthode.

public class Parcel4 {
  public Destination dest(String s) {
    class PDestination
        implements Destination {
      private String label;
      private PDestination(String whereTo) {
        label = whereTo;
      }
      public String readLabel() { return label; }
    }
    return new PDestination(s);
  }
  public static void main(String[] args) {
    Parcel4 p = new Parcel4();
    Destination d = p.dest("Tanzania");
  }
} ///:~

La classe PDestination appartient à dest() plutôt qu'à Parcel4 (notez aussi qu'on peut utiliser l'identifiant PDestination pour une classe interne à l'intérieur de chaque classe du même sous-répertoire sans collision de nom). Cependant, PDestination ne peut être accédée en dehors de dest(). Notez le transtypage ascendant réalisé par l'instruction de retour - dest() ne renvoie qu'une référence à Destination, la classe de base. Bien sûr, le fait que le nom de la classe PDestination soit placé à l'intérieur de dest() ne veut pas dire que PDestination n'est pas un objet valide une fois sorti de dest().

L'exemple suivant montre comment on peut imbriquer une classe interne à l'intérieur de n'importe quelle portée :

//: c08:Parcel5.java
// Définition d'une classe à l'intérieur d'une portée quelconque.

public class Parcel5 {
  private void internalTracking(boolean b) {
    if(b) {
      class TrackingSlip {
        private String id;
        TrackingSlip(String s) {
          id = s;
        }
        String getSlip() { return id; }
      }
      TrackingSlip ts = new TrackingSlip("slip");
      String s = ts.getSlip();
    }
    // Utilisation impossible ici ! En dehors de la portée :
    //! TrackingSlip ts = new TrackingSlip("x");
  }
  public void track() { internalTracking(true); }
  public static void main(String[] args) {
    Parcel5 p = new Parcel5();
    p.track();
  }
} ///:~

La classe TrackingSlip est définie dans la portée de l'instruction if. Cela ne veut pas dire que la classe est créée conditionnellement - elle est compilée avec tout le reste. Cependant, elle n'est pas accessible en dehors de la portée dans laquelle elle est définie. Mis à part cette restriction, elle ressemble à n'importe quelle autre classe ordinaire.

Classes internes anonymes

L'exemple suivant semble relativement bizarre :

//: c08:Parcel6.java
// Une méthode qui renvoie une classe interne anonyme.

public class Parcel6 {
  public Contents cont() {
    return new Contents() {
      private int i = 11;
      public int value() { return i; }
    }; // Point-virgule requis dans ce cas
  }
  public static void main(String[] args) {
    Parcel6 p = new Parcel6();
    Contents c = p.cont();
  }
} ///:~

La méthode cont() combine la création d'une valeur de retour avec la définition de la classe de cette valeur de retour ! De plus, la classe est anonyme - elle n'a pas de nom. Pour compliquer le tout, il semble qu'on commence par créer un objet Contents :

return new Contents()

Mais alors, avant de terminer l'instruction par un point-virgule, on dit : « Eh, je crois que je vais insérer une définition de classe » :

return new Contents() {

  private int i = 11;
  public int value() { return i; }
};

Cette étrange syntaxe veut dire : « Crée un objet d'une classe anonyme dérivée de Contents ». La référence renvoyée par l'expression new est automatiquement transtypée vers une référence Contents. La syntaxe d'une classe interne anonyme est un raccourci pour :

class MyContents implements Contents {
  private int i = 11;
  public int value() { return i; }
}
return new MyContents();

Dans la classe interne anonyme, Contents est créée avec un constructeur par défaut. Le code suivant montre ce qu'il faut faire dans le cas où la classe de base dispose d'un constructeur requérant un argument :

//: c08:Parcel7.java
// Une classe interne anonyme qui appelle
// le constructeur de la classe de base.

public class Parcel7 {
  public Wrapping wrap(int x) {
    // Appel du constructeur de la classe de base :
    return new Wrapping(x) {
      public int value() {
        return super.value() * 47;
      }
    }; // Point-virgule requis
  }
  public static void main(String[] args) {
    Parcel7 p = new Parcel7();
    Wrapping w = p.wrap(10);
  }
} ///:~

Autrement dit, on passe simplement l'argument approprié au constructeur de la classe de base, vu ici comme le x utilisé dans new Wrapping(x). Une classe anonyme ne peut avoir de constructeur dans lequel on appellerait normalement super().

Dans les deux exemples précédents, le point-virgule ne marque pas la fin du corps de la classe (comme il le fait en C++). Il marque la fin de l'expression qui se trouve contenir la définition de la classe anonyme. Son utilisation est donc similaire à celle que l'on retrouve partout ailleurs.

Que se passe-t-il lorsque certaines initialisations sont nécessaires pour un objet d'une classe interne anonyme ? Puisqu'elle est anonyme, on ne peut donner de nom au constructeur - et on ne peut donc avoir de constructeur. On peut néanmoins réaliser des initialisations lors de la définition des données membres :

//: c08:Parcel8.java
// Une classe interne anonyme qui réalise
// des initialisations. Une version plus courte
// de Parcel5.java.

public class Parcel8 {
  // L'argument doit être final pour être utilisé
  // la classe interne anonyme :
  public Destination dest(final String dest) {
    return new Destination() {
      private String label = dest;
      public String readLabel() { return label; }
    };
  }
  public static void main(String[] args) {
    Parcel8 p = new Parcel8();
    Destination d = p.dest("Tanzania");
  }
} ///:~

Si on définit une classe interne anonyme et qu'on veut utiliser un objet défini en dehors de la classe interne anonyme, le compilateur requiert que l'objet extérieur soit final. C'est pourquoi l'argument de dest() est final. Si le mot-clef est omis, le compilateur générera un message d'erreur.

Tant qu'on se contente d'assigner un champ, l'approche précédente est suffisante. Mais comment faire si on a besoin de réaliser plusieurs actions comme un constructeur peut être amené à le faire ? Avec l'initialisation d'instances, on peut, dans la pratique, créer un constructeur pour une classe interne anonyme :

//: c08:Parcel9.java
// Utilisation des « initialisations d'instances » pour
// réaliser la construction d'une classe interne anonyme.

public class Parcel9 {
  public Destination
  dest(final String dest, final float price) {
    return new Destination() {
      private int cost;
      // Initialisation d'instance pour chaque objet :
      {
        cost = Math.round(price);
        if(cost > 100)
          System.out.println("Over budget!");
      }
      private String label = dest;
      public String readLabel() { return label; }
    };
  }
  public static void main(String[] args) {
    Parcel9 p = new Parcel9();
    Destination d = p.dest("Tanzania", 101.395F);
  }
} ///:~

A l'intérieur de l'initialisateur d'instance on peut voir du code pouvant ne pas être exécuté comme partie d'un initialisateur de champ (l'instruction if). Dans la pratique, donc, un initialisateur d'instance est un constructeur pour une classe interne anonyme. Bien sûr, ce mécanisme est limité ; on ne peut surcharger les initialisateurs d'instance et donc on ne peut avoir qu'un seul de ces constructeurs.

Lien vers la classe externe

Jusqu'à présent, les classes internes apparaissent juste comme un mécanisme de camouflage de nom et d'organisation du code, ce qui est intéressant mais pas vraiment indispensable. Cependant, elles proposent un autre intérêt. Quand on crée une classe interne, un objet de cette classe interne possède un lien vers l'objet extérieur qui l'a créé, il peut donc accéder aux membres de cet objet externe - sans aucune qualification spéciale. De plus, les classes internes ont accès à tous les éléments de la classe externe  [40]. L'exemple suivant le démontre :

//: c08:Sequence.java
// Contient une séquence d'Objects.

interface Selector {
  boolean end();
  Object current();
  void next();
}

public class Sequence {
  private Object[] obs;
  private int next = 0;
  public Sequence(int size) {
    obs = new Object[size];
  }
  public void add(Object x) {
    if(next < obs.length) {
      obs[next] = x;
      next++;
    }
  }
  private class SSelector implements Selector {
    int i = 0;
    public boolean end() {
      return i == obs.length;
    }
    public Object current() {
      return obs[i];
    }
    public void next() {
      if(i < obs.length) i++;
    }
  }
  public Selector getSelector() {
    return new SSelector();
  }
  public static void main(String[] args) {
    Sequence s = new Sequence(10);
    for(int i = 0; i < 10; i++)
      s.add(Integer.toString(i));
    Selector sl = s.getSelector();    
    while(!sl.end()) {
      System.out.println(sl.current());
      sl.next();
    }
  }
} ///:~

La Sequence est simplement un tableau d'Objects de taille fixe paqueté dans une classe. On peut appeler add() pour ajouter un nouvel Object à la fin de la séquence (s'il reste de la place). Pour retrouver chacun des objets dans une Sequence, il existe une interface appelée Selector, qui permet de vérifier si on se trouve à la fin (end()), de récupérer l'Object courant (current()), et de se déplacer vers l'Object suivant (next()) dans la Sequence. Comme Selector est une interface, beaucoup d'autres classes peuvent implémenter l'interface comme elles le veulent, et de nombreuses méthodes peuvent prendre l'interface comme un argument, afin de créer du code générique.

Ici, SSelector est une classe private qui fournit les fonctionnalités de Selector. Dans main(), on peut voir la création d'une Sequence, suivie par l'addition d'un certain nombre d'objets String. Un Selector est alors produit grâce à un appel à getSelector() et celui-ci est alors utilisé pour se déplacer dans la Sequence et sélectionner chaque item.

Au premier abord, SSelector ressemble à n'importe quelle autre classe interne. Mais regardez-la attentivement. Notez que chacune des méthodes end(), current() et next() utilisent obs, qui est une référence n'appartenant pas à SSelector, un champ private de la classe externe. Cependant, la classe interne peut accéder aux méthodes et aux champs de la classe externe comme si elle les possédait. Ceci est très pratique, comme on peut le voir dans cet exemple.

Une classe interne a donc automatiquement accès aux membres de la classe externe. Comment cela est-il possible ? La classe interne doit garder une référence de l'objet de la classe externe responsable de sa création. Et quand on accède à un membre de la classe externe, cette référence (cachée) est utilisée pour sélectionner ce membre. Heureusement, le compilateur gère tous ces détails pour nous, mais vous pouvez maintenant comprendre qu'un objet d'une classe interne ne peut être créé qu'en association avec un objet de la classe externe. La construction d'un objet d'une classe interne requiert une référence sur l'objet de la classe externe, et le compilateur se plaindra s'il ne peut accéder à cette référence. La plupart du temps cela se fait sans aucune intervention de la part du programmeur.

Classes internes static

Si on n'a pas besoin du lien entre l'objet de la classe interne et l'objet de la classe externe, on peut rendre la classe interne static. Pour comprendre le sens de static quand il est appliqué aux classes internes, il faut se rappeler que l'objet d'une classe interne ordinaire garde implicitement une référence sur l'objet externe qui l'a créé. Ceci n'est pas vrai cependant lorsque la classe interne est static. Une classe interne static implique que :

Ce livre a été écrit par Bruce Eckel ( télécharger la version anglaise : Thinking in java )
Ce chapitre a été traduit par Jérome Quelin ( groupe de traduction )
télécharger la version francaise (PDF) | Commandez le livre en version anglaise (amazon) | télécharger la version anglaise
pages : 1 2 3 4 5 6 
Penser en Java 2nde édition - Sommaire |  Préface |  Avant-propos | Chapitre : 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 |  Annexe : A B C D  | Tables des matières - Thinking in Java