Pourquoi utiliser com.company.project structure?

Si vous démarrez avec un nom de domaine que vous possédez, exprimé à l'envers, alors ce n'est qu'après que vous pouvez vous heurter à quelqu'un d'autre après la même structure, que personne d'autre ne possède ce nom de domaine.

Il est utilisé uniquement sur certaines plates-formes.

Empêcher les affrontements de noms est une raison assez pratique des structures de paquet comme celle-ci. Si vous utilisez de vrais noms de domaine que vous possédez et que tout le monde utilise leurs noms de paquets du même rôle, les affrontements sont hautement improbables.

ESP. Dans le monde Java, il s'agit de "comportement attendu". Il vous aide également si vous souhaitez trouver une documentation pour une bibliothèque héritée que vous utilisez que personne ne peut plus se souvenir d'où il venait de; -)

En ce qui concerne stocker des fichiers dans une telle structure d'emballage: dans les packages mondiaux Java sont des dossiers effectivement des dossiers (ou des chemins dans un fichier .jar) donc: Oui, assez de personnes stockent leurs fichiers de cette façon.

Un autre avantage pratique d'une telle structure est que vous savez toujours si une bibliothèque a été développée en interne ou non.

Je saute souvent le com. Comme même de petits orgs ont plusieurs TLD, mais certainement utiles pour avoir le nom du propriétaire dans l'espace de noms, de sorte que lorsque vous commencez à ouvrir des bibliothèques tiers, vous n'avez pas d'affrontement des espaces de noms.

Pensez simplement combien d'espaces de noms d'utilité ou de journalisation il y aurait autour, voici au moins nous avons foo.logging et bar.logging, et le devient peut alias un espace de noms :)

Plusieurs raisons sont:

• L'utilisation de noms de domaine facilite la réalisation d'unicité, sans ajouter de nouveau registre
• En ce qui concerne la structuration hiérarchique, passez du majeur à mineur est naturel

  Pour le deuxième point, considérez l'exemple de stockage des enregistrements datés dans une structure de fichiers hiérarchique. Il est beaucoup plus judicieux de l'organiser hiérarchiquement comme aaaa / mm / dd que dire jj / mm / aaaa : Au niveau de la racine, vous voyez des dossiers qui organisent des enregistrements par année, puis au prochain niveau par mois, puis finalement par jour. Le faire dans l'autre sens (par jour ou mois au niveau de la racine) serait probablement plutôt gênant.

  Pour les noms de domaine, il va généralement subsubsub.domain.suffix , c'est-à-dire de mineur à majeur. C'est pourquoi, lorsque vous convertissez cela en un nom de package hiérarchique, vous obtenez suffix.domain.subsub .

  Pour le premier point, voici un extrait de Spécification de la langue Java 3ème édition qui peut perdre une lumière dans cette convention de dénomination de l'emballage:

  7.7 Noms de forfaits uniques < / h3>

  Les développeurs doivent prendre des mesures pour éviter la possibilité de deux packages publiés ayant le même nom en choisissant des noms de paquets uniques pour les packages largement distribués. Cela permet d'installer et de cataloguer automatiquement les packages. Cette section spécifie une convention suggérée pour générer des noms de paquet uniques. Les implémentations de la plate-forme Java sont encouragées à fournir une prise en charge automatique pour convertir un ensemble de packages de noms de paquets locaux et occasionnels au format de nom unique décrit ici.

  Si des noms d'emballage uniques ne sont pas utilisés, les conflits de noms de paquet peuvent survenir loin du point de création de l'un ou de l'autre des emballages contradictoires. Cela peut créer une situation difficile, voire impossible pour l'utilisateur ou le programmeur de résoudre. La classe classloader peut être utilisée pour isoler les packages avec le même nom les uns des autres dans les cas où les packages auront des interactions contraintes, mais pas de manière transparente à un programme naïf.

  Vous formez un nom de paquet unique en ayant d'abord (ou appartenant à une organisation qui a) un nom de domaine Internet, tel que sun.com . Vous inversez ensuite ce nom, composant par composant, pour obtenir, dans cet exemple, com.sun et utilisez-le comme préfixe pour vos noms de package, à l'aide d'une convention développée dans votre organisation pour administrer davantage l'emballage. noms.

  Le nom d'un package n'est pas conçu pour impliquer où le colis est stocké sur Internet; Par exemple, un package nommé édu.cmu.cs.bovik.cheese n'est pas nécessairement disponible à partir d'une adresse Internet cmu.edu ou de cs.cmu.edu < / code> ou à partir de bovik.cs.cmu.edu . La Convention suggérée pour générer des noms de forfaits uniques est simplement un moyen de faire la convention de dénomination de packgyback sur un registre de nom unique existant et largement connu au lieu de créer un registre séparé pour les noms de packages .