Résolution des dépendances de package Java

Question

Il est temps de subdiviser une plate-forme que je développe et je recherche des conseils sur la gestion des dépendances inter-composants. Je parle de nombreux cas, alors je vais donner un exemple.

J'ai une classe Address que je veux rendre visible aux développeurs. Il est également référencé par les classes des packages my.Contacts, my.Appointments et my.Location - que je souhaite compiler, jar-d et livrer séparément. Bien sûr, je veux que l'adresse soit une seule classe - une adresse fonctionne de manière transparente entre ces composants de la plate-forme.

Comment l'adresse doit-elle être empaquetée, construite et livrée?

Merci!

Answer 1

Deux pensées:

1. Address sonne comme un élément commun qui peut être utilisé dans différents livrables et doivent donc être disponibles dans certains commun ou noyau bibliothèque
2. Il peut être judicieux pour votre composants pour parler à une interface Address, et l'implémentation peut être fournie séparément (par exemple fournir une interface Address et une implémentation AddressImpl). Cela réduira la quantité de liaison entre la bibliothèque principale et la bibliothèque que vos développeurs développeront.

Answer 2

Dans ce cas, Address est une partie d'une bibliothèque qui mérite son propre pot. Si vous créez une classe nommée Address dans my.Contacts, my.Appointments et my.Location et que vous souhaitez utiliser tous ces jar dans une même application, vous aurez un conflit avec votre classe Address.

Answer 3

Je vous suggère de ne pas "livrer" ces pots séparément. Java a des problèmes de versionnement très subtils que vous ne voulez pas rencontrer. Construisez le tout et emballez-le dans un ou deux pots et livrez toujours les deux pots, ou construisez-les ensemble et fournissez un sous-ensemble de bocaux (mais ne combinez jamais des bocaux neufs et anciens - n'essayez pas d'envoyer un seul bocal comme mise à jour). Si vous devez les compiler séparément, sachez que les constantes finales sont compilées et non référencées. Ainsi, si vous en modifiez une et que vous livrez un nouveau fichier jar, les références d'un ancien fichier ne seront pas mises à jour.

Les signatures de méthodes qui changent auront également des résultats étranges et imprévisibles.

Il semble que vous souhaitiez également une interface de développeur, c'est-à-dire un ensemble d'interfaces et de classes qui résident dans un fichier jar distinct. Si vous faites assez bien ce bocal pour que vous n'ayez jamais à le faire (et, bien sûr, sans référence à des constantes externes), vous pouvez probablement ne pas le mettre à jour, ce qui empêchera les extensions de votre client de devenir croustillantes.