next up previous contents index
Next: Patterns d'accès et discipline Up: Patterns Previous: Une discipline d'abstraction

   
Paquets et accessibilité

   

Les programmes Java sont des familles de types, dont certains sont publics, c'est-à-dire destinés à être accessibles à d'autres utilisateurs que leur auteur. Ces familles de types sont organisées en paquet (ou package), dans le but de garantir une désignation non-ambiguë de chaque type, si possible dans le monde entier. La spécification de Java propose d'utiliser le système des noms de domaine Internet pour assurer cette unicité. Par exemple, tous les types conçus à l'ENPC devraient figurer dans un paquet FR.enpc (en renversant le nom de domaine enpc.fr, et en écrivant le nom de premier niveau en majuscules). Ensuite, de façon interne, l'École pourrait décider de désigner le type public List, dont l'auteur est l'élève toto, par le nom FR.enpc.eleves.toto.List, ce qui le distingue du type java.util.List de l'API de Java.


Les membres d'un paquet sont des types qui sont définis dans des unités de compilation, et des sous-paquets. Par exemple, le paquet java est composé des sous-paquets applet, awt, beans, io, lang, math, net, rmi, security, sql, text et util ; chacun de ses sous-paquets est désigné par son nom complet : java.applet, java.awt, etc.


Une unité de compilation se compose de définitions de types (classes ou interfaces). Par exemple, le paquet java.util contient les définitions des types Collection, Set, HashSet, etc. L'usage est de désigner les paquets par des noms commençant par une minuscule, les classes par des noms commençant par une majuscule, et les membres d'une classe à nouveau par des noms commençant par une minuscule. Ainsi, le nom complet java.lang.System.out désigne le membre out de la classe System du paquet java.lang.


     

   

Les paquets permettent de réaliser une forme de modularité basée sur la visibilité des noms, donc l'accessibilité des entités qu'ils désignent. Les noms dont la visibilité est contrôlable sont ceux des types (classes et interfaces) et ceux des membres et constructeurs de ces types. Les types d'un paquet sont déclarés public ou bien n'ont pas d'indication de visibilité. Les types publics sont accessibles de tout paquet (à condition que le paquet contenant ces types publics soit lui-même accessible) ; les types non publics ne sont accessibles que du paquet où ils sont définis. Seuls les types publics sont documentés. La règle (d'usage) est qu'une unité de compilation contient au plus un type public et qu'elle est placée dans un fichier dont le nom est celui du type public, suffixé par .java. L'unité de compilation suivante doit donc être placée dans un fichier de nom A.java :

package p;

public class A { ... }       // accessible partout
class A1 { ... }             // accessible seulement dans p
class A2 { ... }             // accessible seulement dans p

Les membres d'un type ou les constructeurs d'une classe sont déclarés public, protected ou private ou n'ont pas d'indication de visibilité.

package p;

public class C {
  public int a;              // accessible partout 
  protected int b;           // accessible dans p et 
                             // les sous-classes de C
  int c;                     // accessible dans p
  private int d;             // accessible dans C
}

      Les membres ou constructeurs privés d'une classe ne sont accessibles qu'à l'intérieur de la classe où ils sont définis ; en particulier, ils ne peuvent pas être hérités par les types dérivés. Une méthode privée ne peut pas être redéfinie dans une sous-classe ; il est bien sûr possible de définir dans une sous-classe une méthode de même profil, mais elle n'aura aucune relation avec la méthode correspondante de la sur-classe, et le mécanisme de liaison tardive ne s'appliquera pas.

      Les membres ou constructeurs sans indication de visibilité (ni publics, ni privés, ni protégés) d'une classe sont accessibles de toute classe du même paquet ; en particulier, ils ne sont hérités que par les classes dérivées appartenant au même paquet. Une méthode sans indication de visibilité peut être redéfinie dans une sous-classe par une méthode qui ne doit pas être privée.

      Les membres ou constructeurs protégés d'une classe sont accessibles à partir d'une classe dérivée, à travers une référence qui est un sous-type de cette classe dérivée, ainsi que de toute classe du même paquet ; en particulier, ils peuvent être hérités par les classes dérivées. Une méthode protégée ne peut être redéfinie, dans une sous-classe, que par une méthode publique ou protégée. On notera qu'un membre protégé est davantage visible (ou moins protégé ?) qu'un membre sans indication de visibilité.

      Les membres ou constructeurs publics d'un type public sont accessibles de tout paquet ; en particulier, ils peuvent être hérités par les types dérivés. Une méthode publique ne peut être redéfinie, dans une classe dérivée, que par une méthode publique. Les membres d'une interface sont implicitement déclarés publics.

Les membres et constructeurs publics et protégés doivent être documentés. Java prévoit des commentaires d'une forme particulière (entre /** et */) qui permettent la génération automatique d'une documentation HTML avec la commande javadoc du Java Development Kit. Voici l'exemple de la documentation d'une méthode d'une interface ; le commentaire précède la déclaration de la méthode, comporte des mots-clés spécifiques (@param, @returns) et des balises HTML (<tt>...</tt>) :

    /**
     * Returns <tt>true</tt> if this collection contains 
     * the specified element.  More formally, returns 
     * <tt>true</tt> if and only if this collection contains
     * at least one element <tt>e</tt> such that 
     * <tt>(o==null ? e==null : o.equals(e))</tt>.
     *
     * @param o element whose presence in this collection
     * is to be tested.
     * @return <tt>true</tt> if this collection contains the
     * specified element
     */
    boolean contains(Object o);


next up previous contents index
Next: Patterns d'accès et discipline Up: Patterns Previous: Une discipline d'abstraction
R. Lalement
2000-10-23