Les programmeurs sont un groupe organisé lorsqu'il s'agit d'écrire du code. Ils aiment organiser leurs programmes de manière à ce qu'ils se déroulent de manière logique, en appelant des blocs de code séparés qui ont chacun un travail particulier. L'organisation des classes qu'ils écrivent se fait en créant des packages.
Un package permet à un développeur de regrouper des classes (et des interfaces) ensemble. Ces classes seront toutes liées d'une manière ou d'une autre - elles peuvent toutes être liées à une application spécifique ou effectuer un ensemble spécifique de tâches. Par exemple, le Java L'API regorge de packages. L'un d'eux est le package javax.xml. Elle et ses sous-packages contiennent toutes les classes de l'API Java concernant la gestion XML.
Pour regrouper des classes dans un package, chaque classe doit avoir une instruction package définie en haut de son.fichier java. Il permet au compilateur de savoir à quel package appartient la classe et doit être la première ligne de code. Par exemple, imaginez que vous créez un jeu de cuirassés simple. Il est logique de mettre toutes les classes nécessaires dans un package appelé cuirassés:
C'est là que toutes les classes appartenant à ce package sont stockées. Par exemple, si le package cuirassés contient les classes GameBoard, Ship, ClientGUI, alors il seront des fichiers appelés GameBoard.java, Ship.java et ClientGUI.java stockés dans un appel de répertoire cuirassés.
Par exemple, le nom du package javax.xml indique que XML est un sous-package du package javax. Cela ne s'arrête pas là, sous XML, il y a 11 sous-packages: bind, crypto, type de données, espace de noms, analyseurs, soap, stream, transform, validation, ws et XPath.
Les répertoires du système de fichiers doivent correspondre à la hiérarchie des packages. Par exemple, les classes du package javax.xml.crypto vivront dans une structure de répertoires.. \ javax \ xml \ crypto.
Mais, en ce qui concerne le compilateur, chaque paquet est un ensemble distinct de classes. Il ne considère pas une classe dans un sous-package comme faisant partie de son package parent. Cette distinction devient plus apparente lorsqu'il s'agit d'utiliser des packages.
Dans les éditeurs de logiciels et les grands projets, où les packages peuvent être importés dans d'autres classes, les noms doivent être distinctifs. Si deux packages différents contiennent une classe du même nom, il est important qu'il n'y ait pas de conflit de dénomination. Pour ce faire, assurez-vous que les noms des packages sont différents en démarrant le nom du package avec le domaine de l'entreprise, avant d'être divisé en couches ou fonctionnalités: