Accueil > Collaboration et gestion de projet >
Il y a trois niveaux d’emballages dans Java : les classes, les packages et - depuis la version 9 - les modules. Les packages sont des collections de classes et de sous-packages. Les modules sont des collections de packages et de sous-modules. Les packages et les modules sont utilisés pour organiser les classes et pour contrôler l’accès aux classes.
Un package est un dossier qui contient des classes et des sous-packages. Les packages sont déclarés au début d’un fichier de classe avec le mot-clé package. En créant des packages manuellement, comme dans un explorateur de fichiers ou un éditeur de code comme VS Code, on doit respecter la structure de dossiers. Certains EDI spécialisés, comme Eclipse et IntelliJ, représentent des packages comme une abstraction et on ne voit pas directement la structure des dossiers, mais elle existe toujours.
Les classes qui ne sont pas dans le même package doivent toujours être importées avec le mot-clé import. Les classes qui sont dans le même package n’ont pas besoin d’être importées.
Un module est un ensemble de packages et de sous-modules. Les modules sont déclarés dans un fichier module-info.java avec le mot-clé module. On ne verra pas beaucoup de détails en lien avec les modules dans ce cours, mais l’accès aux packages et aux modules spécifiques est déclaré dans ce fichier avec les mots-clés requires, opens et exports.
Si aucune déclaration de package n’est fait au début d’un fichier de classe, la classe est placée dans le package par défaut. Le package par défaut n’a pas de nom et ne peut pas être importé. Si toutes les classes du projet sont dans le même dossier et il n’y aucune déclaration de package, elles sont toutes dans le package par défaut et elles peuvent toutes s’appeler les unes les autres.
Mais ces classes ne peuvent pas être importées dans d’autres packages (parce que le package par défaut n’a pas de nom).
Le nom pour le package de base d’un projet Java suit souvent la convention d’un nom de domaine inversé. Par exemple, les packages faits par Google sont nommés com.google et les packages faits par Oracle sont nommés com.oracle. Des sous-packages (sous-dossiers), comme com.google.maps et com.oracle.jdbc, sont utilisés pour organiser les classes selon leur fonctionnalité.
Pour ce cours, je vous recommande le nom de package de base edu.ics4u.[prénom] où vous insérez votre prénom en minuscules. Par exemple, si votre prénom est Jenna, votre nom de package de base serait edu.ics4u.jenna. Vous aurez alors la déclaration au format suivant comme première ligne de chaque fichier de classe :
1
package [nom.du.package];
Si toutes vos classes sont dans le package de base, elles peuvent s’appeler les unes les autres sans les importer. Mais si vous organisez vos classes dans différents packages et/ou sous-packages, chaque classe qui n’est pas dans le même package doit être importée avec une déclaration au format :
1
import [nom.de.l'autre.package].[nomDeLaClasse];
Pour qu’une classe soit visible dans un autre package, elle doit être déclarée public. Si une classe n’est pas déclarée public, elle ne peut être utilisée que dans le même package - la visibilité est privée au package par défaut. Ainsi, on peut étendre le concept d’encapsulation au niveau des packages.
Depuis Java 9, on peut aussi encapsuler un ensemble de packages dans des modules. Le JDK est lui-même divisé en modules depuis cette version, mais on ne verra pas les détails dans ce cours.
Le dossier racine de votre projet et le dossier racine de vos packages ne seront généralement pas les mêmes avec les outils standard de développement de projets Java.
Par exemple, avec Maven (dans n’importe quel EDI incluant VS Code), le dossier racine du projet contient un fichier pom.xml qui décrit la configuration du projet et le dossier racine de vos packages est, par défaut, src/main/java. Si votre package de base est edu.ics4u.nathan, alors le fichier App.java serait dans le dossier src/main/java/edu/ics4u/nathan. Notez que par défaut Maven définit aussi un dossier src/test/java pour les tests unitaires, p. ex. dans un fichier AppTest.java.
Avec des EDI comme Eclipse et IntelliJ, la structure du dossier de projet est configuré par l’EDI même si ce n’est pas un projet Maven. Par exemple, avec Eclipse le dossier racine du projet contient des fichiers de configuration qui sont souvent masqués et le dossier racine de vos packages est src. Parce que ces EDI utilisent une abstraction pour les packages Java, un package, p. ex. edu.ics4u.mohammed, sera visible comme un objet dans le dossier src et on ajoute une nouvelle classe, p. ex. App, directement dans le package.
À la fin de cette leçon vous devrez être en mesure de :