Lorsque vous utilisez le système de module Java 9, vous devez prêter attention aux spécifications de dénomination, au contr?le des emballages, à la gestion des dépendances, à l'utilisation automatique des modules et à la conception en couches. Il est recommandé d'adopter un style de nom de domaine inversé tel que com.example.mymodule pour éviter les conflits et améliorer la reconnaissance; Essayez d'être clair dans la sémantique, n'utilisez pas de noms vagues ou en double et ne commencez pas par des chiffres ou des caractères spéciaux. Les exportations et les exigences doivent être clairement définies à l'intérieur du module, seuls les packages nécessaires doivent être exportés, les dépendances doivent être explicitement déclarées et la maintenabilité doit être améliorée et le couplage doit être évité. Utilisez des modules automatiques avec prudence et donnez la priorité aux bibliothèques modulaires. Si nécessaire, confirmez la stabilité du nom de leur module et évitez de cartographier les conflits. Le chemin-module correct doit être configuré dans l'outil de construction au lieu de l'ancien chemin de classe. La structure du module doit être raisonnablement en couches, telles que la mise en place de l'interface, de la mise en ?uvre et du programme principal dans différents modules pour améliorer la clarté du projet et l'évolutivité. Planifiez les limites du module à l'avance pour assurer une maintenance à long terme pratique.

Le système de modules (puzzle) introduit dans Java 9 rend la structure du projet plus claire et la gestion des dépendances plus claire, mais il y a en fait certaines choses à faire avec cela. Cet article ne parle pas des principes, mais seulement des suggestions pratiques.

La dénomination des modules doit être standardisée, alors ne vous évitez pas de problèmes

Bien que le nom du module ne soit qu'une cha?ne, elle affectera la maintenabilité de l'ensemble du projet. Il est recommandé d'utiliser uniformément les styles de noms de domaine inverse, tels que com.example.mymodule , qui peuvent éviter de nommer les conflits et faciliter l'identification de l'attribution.

Certaines personnes aiment appeler core ou utils directement, ce qui est OK dans de petits projets, mais il est facile de se confondre lors de la collaboration avec de grandes équipes ou plusieurs personnes. Si vous devez utiliser un nom court, au moins le préfixer, par exemple com.example.core .

• Essayez d'être sémantique et clair
• évitez les noms de modules en double ou flou
• Ne commencez pas par des chiffres ou des personnages étranges

Exportations et exigences clairement, ne les exposez pas toutes

L'un des plus grands avantages d'un système de modules est sa capacité d'emballage. exports pas tous les packages pour des raisons de commodité. Exposer uniquement les pièces qui doivent vraiment être visibles à l'extérieur, tandis que le reste reste caché à l'intérieur peut effectivement empêcher une mauvaise utilisation et un couplage excessif.

Dans le même temps, requires doivent être rédigées clairement, en particulier lors de l'appel à travers des modules. Si vous comptez sur un module, assurez-vous de le déclarer explicitement et ne vous attendez pas à ce que le JVM le gère automatiquement.

Par exemple:

 module com.example.service {
    exiger com.example.api;
    Exports com.example.service.impl;
}

Dans le code ci-dessus:

• Seul impl est exporté et d'autres packages ne sont pas visibles par défaut au public.
• Il s'appuie explicitement sur le module com.example.api

De cette fa?on, d'autres sauront ce que dépend de votre module et des services que vous fournissez.

Soyez prudent lorsque vous utilisez des modules automatiques

Certains anciens projets ou bibliothèques tiers ne sont pas encore modulaires, donc Java vous permet de les introduire via automatic modules . Bien que pratique, cette approche est risquée: le JVM déduit automatiquement les noms de modules, ce qui peut entra?ner des conflits ou difficile à retracer.

suggestion:

• Essayez d'utiliser des bibliothèques modulaires
• Si vous devez utiliser le module automatique, il est préférable de confirmer si le nom du module automatiquement déduit est stable
• évitez plusieurs bibliothèques mappant au même nom de module automatique

De plus, lorsque vous utilisez JPMS dans des outils de construction tels que Maven ou Gradle, veillez à configurer le chemin du module correct ( --module-path ) au lieu de l'ancien chemin de classe ( -classpath ).

Conception en couches de la structure des modules, ne vous en faites pas un pot entier de bouillie

Le système de modules ne vous permet pas de déchirer un tas de fichiers à volonté, mais vous encourage à faire une superposition raisonnable. Par exemple, une approche commune consiste à séparer l'interface et la mise en ?uvre en différents modules, comme ceci:

• com.example.api : définit l'interface, type public
• com.example.service : implémenter une logique spécifique
• com.example.app : entrée principale du programme, combinant divers modules

Cette structure est claire et facile à entretenir, et est également pratique pour les tests et la mise en ?uvre de remplacement.

Si vous créez un gros module depuis le début, il sera très difficile de le diviser plus tard. La planification des limites du module à l'avance est très importante pour l'entretien à long terme.

Fondamentalement, c'est tout. Le système de modules lui-même n'est pas compliqué, mais lorsqu'il est vraiment mis en ?uvre dans le projet, vous devez toujours faire attention aux détails, sinon il deviendra facilement "il semble avoir utilisé des modules, mais c'est en fait la même chose qu'auparavant".

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!