Construction d’un programme Java

Construction d’un programme Java

Il y a plusieurs autres éléments à comprendre avant de voir le premier programme Java.

Visibilité des noms

Un problème commun à tous les langages de programmation est le contrôle des noms. Si on utilise un nom dans un module du programme et si un autre programmeur utilise le même nom dans un autre module, comment distingue-t-on un nom d’un autre et comment empêche-t-on les « collisions » de noms ? En C c’est un problème particulier car un programme est souvent un océan de noms incontrôlable. Les classes C++ (sur lesquelles les classes Java sont basées) imbriquent les fonctions dans les classes de telle sorte qu’elles ne peuvent pas entrer en collision avec les noms de fonctions imbriqués dans d’autres classes. Toutefois, C++ autorise toujours les données et les fonctions globales, donc les collisions sont toujours possibles. Pour résoudre ce problème, C++ a introduit les domaines de noms (namespace) en utilisant des mots-clefs supplémentaires.

Java a pu éviter tout cela en employant une approche originale. Pour générer sans ambiguïté un nom pour une bibliothèque, le spécificateur utilisé n’est pas très différent d’un nom de domaine Internet. En fait, les créateurs de Java veulent qu’on utilise son propre nom de domaine Internet inversé, puisqu’on est assuré que ceuxci sont uniques. Puisque mon nom de domaine est BruceEckel.com, ma bibliothèque d’utilitaires (utility) pour mes marottes (foibles) devrait être appelée com.bruceeckel.utility.foibles. Après avoir inversé le nom de domaine, les points sont destinés à représenter des sous-répertoires. Dans Java 1.0 et Java 1.1 les extensions de domaines com, edu, org, net, etc. étaient mises en lettres capitales par convention, ainsi la bibliothèque serait : COM.bruceeckel.utility.foibles. Toutefois, au cours du développement de Java 2, on s’est rendu compte que cela causait des problèmes et par conséquent les noms de packages sont entièrement en lettres minuscules. Ce mécanisme signifie que tous les fichiers existent automatiquement dans leur propre domaine de nom et toutes les classe contenues dans un fichier donné doivent avoir un identificateur unique. Ainsi, on n’a pas besoin d’apprendre de particularités spécifiques au langage pour résoudre ce problème — le langage s’en occupe à votre place.

Utilisation d’autres composantes

Lorsqu’on souhaite utiliser une classe prédéfinie dans un programme, le compilateur doit savoir comment la localiser. Bien entendu, la classe pourrait déjà exister dans le même fichier source que celui d’où elle est appelée. Dans ce cas on utilise simplement la classe — même si la classe n’est définie que plus tard dans le fichier. Java élimine le problème des « référence anticipées », il n’y a donc pas à s’en préoccuper. Qu’en est-il des classes qui existent dans un autre fichier ? On pourrait penser que le compilateur devrait être suffisamment intelligent pour aller simplement la chercher lui même, mais il y a un problème. Imaginons que l’on veuille utiliser une classe ayant un nom spécifique mais qu’il existe plus d’une classe ayant cette définition (il s’agit probablement de définitions différentes). Ou pire, imaginons que l’on écrive un programme et qu’en le créant on ajoute à sa bibliothèque une nouvelle classe qui entre en conflit avec le nom d’une classe déjà existante. Pour résoudre ce problème il faut éliminer les ambiguïtés potentielles. Ceci est réalisé en disant exactement au compilateur Java quelles classes on souhaite, en utilisant le mot-clef import. import dit au compilateur d’introduire un package qui est une bibliothèque de classes (dans d’autres langages, une bibliothèque pourrait comporter des fonctions et des données au même titre que des classes mais il faut se rappeler que tout le code Java doit être écrit dans des classes). La plupart du temps on utilise des composantes des bibliothèques Java standard qui sont fournies avec le compilateur. Avec celles-ci il n’y a pas à se tracasser à propos des longs noms de domaines inversés ; il suffit de dire, par exemple : import java.util.ArrayList;
pour dire au compilateur que l’on veut utiliser la classe Java ArrayList. Toutefois, util contient de nombreuses classes et on pourrait vouloir utiliser plusieurs d’entre elles sans les déclarer explicitement. Ceci est facilement réalisé en utilisant ‘*’ pour indiquer un joker : import java.util.*;
Il est plus courant d’importer une collection de classes de cette manière que d’importer les classes individuellement.

Le mot-clef static

Normalement, quand on crée une classe, on décrit ce à quoi ressemblent les objets de cette classe et comment ils se comportent. Rien n’existe réellement avant de créer un objet de cette classe avec new ; à ce moment la zone de données est créée et les méthodes deviennent disponibles. Mais il y a deux situation pour lesquelles cette approche n’est pas suffisante. L’une, si on veut avoir une zone de stockage pour des données spécifiques, sans tenir compte du nombre d’objets créés, ou même si aucun objet n’a été créé. L’autre, si on a besoin d’une méthode qui n’est associée à aucun objet particulier de la classe. C’est à dire si on a besoin d’une méthode qui puisse être appelée même si aucun objet n’a été créé. On peut obtenir ces deux effets avec le mot-clef static. Dire que quelque chose est static signifie que la donnée ou la méthode n’est pas spécifiquement rattachée à un objet instance de cette classe. Donc, même si aucun objet de cette classe n’a jamais été créé il est possible d’appeler une méthode static ou d’accéder à une donnée static. Avec des données et des méthodes non static ordinaires il faut connaître l’objet spécifique avec lequel elles fonctionnent. Bien entendu, étant donné que les méthodes static n’ont pas besoin qu’un objet soit créé avant d’être utilisées, elles ne peuvent pas accéder directement à des membres ou des méthodes non static en appelant ces autres membres sans faire référence à un objet nommé (puisque les membres et méthodes non static doivent être rattachés à un objet spécifique).