Exemple de classe encapsulée en Java
Les projets Java que nous avons considérés jusqu'ici étaient limités à une seule classe: la classe fenêtre de l'application. Dans ce contexte, les notions d'encapsulation et de visibilité des membres n'ont évidemment pas d'intérêt.
Dans le premier exemple, nous avons présenté un projet utilisant deux classes: la classe fenêtre et la classe Voiture. Dans ce projet, la classe Voiture était déclarée à l'intérieur de la classe fenêtre. Or lorsqu'une classe est déclarée à l'intérieur d'une autre, la classe interne peut forcément accéder à tous les membres de l'autre et inversement.
Pour que la notion de visibilité ait un intéret, il nous faut donc considérer un projet contenant au minimum deux classes, sans que l'une de ces deux classes ne soient déclarée à l'intérieur de l'autre.
Reprenons le projet Voiture2 en le séparant en deux fichiers:
- le fichier Voiture3.java contiendra la déclaration de la classe fenêtre.
- le fichier Voiture.java contiendra la déclaration de la classe Voiture.
Ce projet se trouve dans Exemple-Java-ProgObjet1/Voiture3.
L'interface graphique du projet contient un bouton supplémentaire qui permet de modifier le compteur de la voiture:
Visibilité des membres de la classe fenêtre
Voici la déclaration de la classe fenêtre (nous avons ommis intentionnellement les corps des méthodes):
public class Voiture3 extends javax.swing.JFrame {
Voiture LaVoiture ;
public Voiture3() {...
private void BT_RoulerActionPerformed(...) {
private void BT_CreerActionPerformed(...) {
private void BT_ModifCompteurActionPerformed(...) {
public static void main(String args[]) {
private javax.swing.JButton BT_Creer;
private javax.swing.JButton BT_ModifCompteur;
private javax.swing.JButton BT_Rouler;
private javax.swing.JTextField CT_Compteur;
private javax.swing.JTextField CT_Distance;
private javax.swing.JTextField CT_Immat;
private javax.swing.JLabel jLabel1;
private javax.swing.JLabel jLabel2;
private javax.swing.JLabel jLabel3;
}
En Java, un membre est publique si sa déclaration est précédée du mot clé public. Il est privé, s'il elle précédée du mot clé private. Par défaut, si rien n'est précisé, la visibilité est publique.
Dans notre exemple:
- LaVoiture est un attribut publique. Il sera destiné à contenir l'adresse d'une nouvelle instance de la classe.
- Voiture3, constructeur de la classe fenêtre généré automatiquement par NetBeans, est une méthode publique.
- les procédures évènementielles associées aux trois boutons (BT_Rouler, BT_Creer et BT_ModifCompteur) sont des méthodes privées.
- la méthode main est publique.
- les neuf composants de la fenêtre sont des attributs privés. Conséquence importante de ceci: depuis la classe Voiture, nous ne pourrons ni afficher des informations dans la fenêtre de l'application, ni lire des informations depuis cette même fenêtre. Autrement dit, les instructions de lecture et d'affichage devront nécessairement figurer dans la classe fenêtre.
La classe Voiture
La classe Voiture est à présent définie dans un fichier séparé et non pas à l'intérieur de la classe fenêtre, comme dans l'exemple précédent. Voici sa déclaration (en ommettant les corps des méthodes):
public class Voiture {
private int Compteur;
private String Immat ;
public int getCompteur () { ...}
public void setCompteur (int c) {...}
public Voiture (String im) {...}
public boolean Rouler (int Km) {...}
private boolean ChangerPneu () {... }
}
Tous les attributs de cette classe sont privés. Nous avons donc ici un exemple de classe encapsulée.
L'encapsulation d'une classe interdit d'accéder à ses attributs depuis l'extérieur, mais elle autorise d'y accéder indirectement via des méthodes. Les méthodes jouant ce rôle sont appelées des accesseurs. On distingue les accesseurs en lecture des accesseurs en écriture:
- les accesseurs en lecture permettent simplement de "lire la valeur d'un attribut. Par convention, le nom de ces méthodes commence par get et est suivi du nom de l'attribut. Dans notre exemple, la méthode getCompteur joue ce rôle. Elle nous permet d'obtenir la valeur de l'attribut Compteur. Comme les accesseurs en lecture doivent retourner une valeur (celle de l'attribut associé) ce sont donc nécessairement des méthodes de type fonction.
- les accesseurs en écriture permettent de modifier la valeur d'un attribut. Ce sont des méthodes de type procédure, prenant en paramètre la nouvelle valeur de l'attribut. Par convention, le nom de ces méthodes commence par set et est suivi du nom de l'attribut. Dans notre exemple, la méthode setCompteur joue le rôle d'un accesseur en écriture. C'est l'accesseur en écriture de l'attribut Compteur.
Vous constaterez que la méthode AfficherAttributs a disparue. Nous avons été obligé de l'enlever car les composants de la classe fenêtre sont privés. Il est donc à présent impossible d'afficher quoi que ce soit dans la fenêtre de l'application depuis la classe Voiture !
Pour la même raison, nous avons modifié le code de la méthode Rouler:
public boolean Rouler (int Km) {
if (! ChangerPneu() )
{
Compteur = Compteur + Km ; return true;
}
else return false;
}
les instructions d'affichage qui y figuraient on disparues. Il s'agit à présent d'une méthode de type fonction booléenne qui retourne la valeur true si la voiture peut rouler (c'est à dire qu'il n'est pas nécessaire de changer les pneus).
Remarquer que la méthode ChangerPneu n'est pas utilisable à l'extérieur de la classe, puisqu'elle est privée. Mais ceci n'est pas un problème, car nous n'en avons besoin que pour tester si la voiture peut rouler. Donc à l'intérieur de la méthode Rouler.
Utilisation de la classe Voiture
Voyons à présent comment la classe Voiture peut être utilisée depuis la classe fenêtre.
Voici la procédure évènementielle du bouton Nouvelle voiture:
private void BT_CreerActionPerformed(..) {
LaVoiture = new Voiture (es.Lire (CT_Immat));
es.Afficher(LaVoiture.getCompteur(), CT_Compteur);
}
comme nous ne pouvons pas accéder directement à l'attribut Compteur, on y accède par un appel de l'accesseur getCompteur, ce qui nous permet de l'afficher.
De même la procédure évènementielle du bouton Rouler a été modifiée pour prendre en compte l'encapsulation de la classe Voiture et l'absence d'instruction d'affichage dans cette classe:
private void BT_RoulerActionPerformed(...) {
int d ;
d = es.LireEntier (CT_Distance);
if (LaVoiture.Rouler(d))
es.Afficher(LaVoiture.getCompteur(), CT_Compteur);
else
es.AfficherMessage("Vos pneus sont usés !");
}
la méthode Rouler est publique et donc utilisable depuis la classe fenêtre. Encore une fois, la valeur de l'attribut Compteur est obtenue via son accesseur en lecture.
Enfin, voici le code de la procédure évènementielle du nouveau bouton Modifier le compteur:
private void BT_ModifCompteurActionPerformed(...) {
int c;
c = es.LireEntier(CT_Compteur);
LaVoiture.setCompteur(c);
}
ici, c'est l'accesseur en écriture de l'attribut Compteur qui est utilisé. Notez que si nous avions voulu rendre le compteur de nos voitures infalsifiable, il aurait suffit de ne pas mettre d'accesseur en écriture sur cet attribut.
On y gagne quoi ?
Arrivé à ce point, le lecteur pourra se demander ce que l'on a gagné avec l'encapsulation. Au premier abord, cela parait plus compliqué puisque l'on ne peut plus accéder aux attributs librement. On a l'impression de s'imposer inutilement des contraintes.
L'intéret de l'encapsulation est essentiellement dans la facilité de mise à jour d'un logiciel. Dans notre exemple, la classe Voiture est à présent facilement réutilisable dans d'autres contextes. En particulier, elle ne dépend plus de l'interface graphique du projet puisqu'elle n'accéde plus de manière directe à la fenêtre de l'application.
D'autre part, nous pouvons à présent modifier la représentation des données de la classe Voiture sans que cela affecte son utilisation. On pourrait par exemple ajouter un nouvel attribut privé: un booléen indiquant si les pneus sont usé. Tant que l'utilisation des méthodes (publiques forcément) de la classe Voiture est inchangée, cette modification sera totalement transparente à l'utilisateur de la classe.
On peut également mettre en doute l'intéret des accesseurs, surtout lorqu'il s'agit simplement de lire ou de modifier la valeur d'un attribut. N'est-il pas plus simple dans ce cas d'accéder directement à cet attribut ? Oui, mais l'accès aux attributs par des accesseurs vous donne certains avantages:
- la possibilité de changer la représentation d'un attribut sans que cela affecte l'utilisation de la classe. Dans notre exemple, on pourrait par exemple passer à une représentation interne codée du numéro d'immatriculation.
- les accesseurs en écriture vous donnent la possibilité d'effectuer des contrôles lors de la modification de la valeur d'un attribut. Dans notre exemple, on pourrait par exemple interdire une diminution de la valeur du compteur.
