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 

Les interfaces et les classes internes sont des manières plus sophistiquées d'organiser et de contrôler les objets du système construit.

C++, par exemple, ne propose pas ces mécanismes, bien que le programmeur expérimenté puisse les simuler. Le fait qu'ils soient présents dans Java indique qu'ils furent considérés comme assez importants pour être intégrés directement grâce à des mots-clefs.

Dans le chapitre 7, on a vu le mot-clef abstract, qui permet de créer une ou plusieurs méthodes dans une classe qui n'ont pas de définition - on fournit une partie de l'interface sans l'implémentation correspondante, qui est créée par ses héritiers. Le mot-clef interface produit une classe complètement abstraite, qui ne fournit absolument aucune implémentation. Nous verrons qu'une interface est un peu plus qu'une classe abstraite poussée à l'extrême, puisqu'elle permet d'implémenter « l'héritage multiple » du C++ en créant une classe qui peut être transtypée en plus d'un type de base.

Les classes internes ressemblent au premier abord à un simple mécanisme de dissimulation de code : on crée une classe à l'intérieur d'autres classes. Cependant, les classes internes font plus que cela - elles connaissent et peuvent communiquer avec la classe principale - ; sans compter que le code produit en utilisant les classes internes est plus élégant et compréhensible, bien que ce soit un concept nouveau pour beaucoup. Cela prend un certain temps avant d'intégrer les classes internes dans la conception.

Interfaces

Le mot-clef interface pousse le concept abstract un cran plus loin. On peut y penser comme à une classe « purement » abstract. Il permet au créateur d'établir la forme qu'aura la classe : les noms des méthodes, les listes d'arguments et les types de retour, mais pas les corps des méthodes. Une interface peut aussi contenir des données membres, mais elles seront implicitement static et final. Une interface fournit un patron pour la classe, mais aucune implémentation.

Une interface déclare : « Voici ce à quoi ressemblera toutes les classes qui implémenteront cette interface ». Ainsi, tout code utilisant une interface particulière sait quelles méthodes peuvent être appelées pour cette interface, et c'est tout. Une interface est donc utilisée pour établir un « protocole » entre les classes (certains langages de programmation orientés objets ont un mot-clef protocol pour réaliser la même chose).

 Pour créer une interface, il faut utiliser le mot-clef interface à la place du mot-clef class. Comme pour une classe, on peut ajouter le mot-clef public devant le mot-clef interface (mais seulement si l'interface est définie dans un fichier du même nom) ou ne rien mettre pour lui donner le statut « amical » afin qu'elle ne soit utilisable que dans le même package.

Le mot-clef implements permet de rendre une classe conforme à une interface particulière (ou à un groupe d'interfaces). Il dit en gros : « L'interface spécifie ce à quoi la classe ressemble, mais maintenant on va spécifier comment cela fonctionne ». Sinon, cela s'apparente à de l'héritage. Le diagramme des instruments de musique suivant le montre :

Image

Une fois une interface implémentée, cette implémentation devient une classe ordinaire qui peut être étendue d'une façon tout à fait classique.

On peut choisir de déclarer explicitement les méthodes d'une interface comme public. Mais elles sont public même sans le préciser. C'est pourquoi il faut définir les  méthodes d'une interface comme public quand on implémente une interface. Autrement elles sont « amicales » par défaut, impliquant une réduction de l'accessibilité d'une méthode durant l'héritage, ce qui est interdit par le compilateur Java.

On peut le voir dans cette version modifiée de l'exemple Instrument. Notons que chaque méthode de l'interface n'est strictement qu'une déclaration, la seule chose que le compilateur permette. De plus, aucune des méthodes d'Instrument n'est déclarée comme public, mais elles le sont automatiquement.

//: c08:music5:Music5.java
// Interfaces.
import java.util.*;

interface Instrument {
  // Constante compilée :
  int i = 5; // static & final
  // Définitions de méthodes interdites :
  void play(); // Automatiquement public
  String what();
  void adjust();
}

class Wind implements Instrument {
  public void play() {
    System.out.println("Wind.play()");
  }
  public String what() { return "Wind"; }
  public void adjust() {}
}

class Percussion implements Instrument {
  public void play() {
    System.out.println("Percussion.play()");
  }
  public String what() { return "Percussion"; }
  public void adjust() {}
}

class Stringed implements Instrument {
  public void play() {
    System.out.println("Stringed.play()");
  }
  public String what() { return "Stringed"; }
  public void adjust() {}
}

class Brass extends Wind {
  public void play() {
    System.out.println("Brass.play()");
  }
  public void adjust() {
    System.out.println("Brass.adjust()");
  }
}

class Woodwind extends Wind {
  public void play() {
    System.out.println("Woodwind.play()");
  }
  public String what() { return "Woodwind"; }
}

public class Music5 {
  // Le type n'est pas important, donc les nouveaux
  // types ajoutés au système marchent sans problème :
  static void tune(Instrument i) {
    // ...
    i.play();
  }
  static void tuneAll(Instrument[] e) {
    for(int i = 0; i < e.length; i++)
      tune(e[i]);
  }
  public static void main(String[] args) {
    Instrument[] orchestra = new Instrument[5];
    int i = 0;
    // Transtypage ascendant durant le stockage dans le tableau :
    orchestra[i++] = new Wind();
    orchestra[i++] = new Percussion();
    orchestra[i++] = new Stringed();
    orchestra[i++] = new Brass();
    orchestra[i++] = new Woodwind();
    tuneAll(orchestra);
  }
} ///:~

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