En Java, Quelle est la motivation technique pour extraire toutes les interfaces dans un projet séparé?
J'ai vu des projets Java où les interfaces sont toutes extraites dans un projet séparé.
Quelle est la motivation pour cela? Est-ce juste organisationnel?
Par exemple, le projet atmosphere le fait. J'ai vu d'autres.
J'envisage de l'utiliser comme principe d'organisation sur un projet que je cours et j'aimerais savoir quels autres avantages il peut fournir.
2 réponses
Il existe un cas d'utilisation: Java SPI, interface du fournisseur de services . Les interfaces sont fournies séparément, et les implémentations (alternatives) sont fournies séparément. Par une entrée manifeste avec le nom de l'interface, en utilisant une interface, on peut trouver tout / n'importe quel fournisseur de cette interface. Les implémentations XML Xalan et Xerces viennent à l'esprit.
Aussi, sans que SPI puisse fournir plusieurs implémentations, comme un prototype de développement piloté par des tests, peut avoir du sens.
Juste pour offrir mes 2 cents,
Je travaille actuellement sur un projet C# qui a un projet séparé contenant toutes les interfaces. Le projet a été nommé "framework" et faisait partie d'un projet plus vaste comprenant plus de 10 implémentations d'interfaces de ce projet de framework. Ma conjecture était (ce qui est également confirmé plus tard par mon supérieur immédiat) est qu'il sépare complètement les implémentations de la conception , quelque chose appelé loose coupling .
De cette façon divers projets qui héritent du projet de cadre peut être développé séparément ou échangé indépendamment. D'un développeur qui est nouveau dans le projet, il est plus facile pour lui/elle de se familiariser avec toutes les méthodes qui sont utilisées dans d'autres projets dans un endroit central. L'ajout de nouvelles méthodes ou la suppression d'anciennes sont tous effectués dans un projet, et tous les autres projets qui utilisent ces interfaces ont un "contrat" strict à suivre. en substance il aide à maintenir le projet à long terme.
Il est également plus facile de créer des maquettes de certaines parties du framework pendant les tests, d'isoler chaque classe individuellement et de les tester pour d'éventuelles erreurs.
Il aide à adhérer au principe de ségrégation d'interface dans lequel si une interface particulière a par exemple seulement une méthode' save', mais nous avons besoin de ' log 'et de' read ' pour des classes d'implémentation spécifiques, nous pouvons simplement créer une autre interface qui héritera de l'interface parent, tout dans le projet de cadre, et pas de patauger dans différents projets pour trouver l'interface que nous voulons ajouter. j'ai trouvé ceci lors de la recherche sur le principe de ségrégation D'Interface.