Ho visto progetti Java in cui tutte le interfacce sono state estratte in un progetto separato.In Java, qual è la motivazione tecnica per l'estrazione di tutte le interfacce in un progetto separato?
Qual è la motivazione? È solo organizzativo?
Ad esempio, il progetto atmosfera lo fa. Ne ho visti altri
Sto pensando di utilizzarlo come principio organizzativo per un progetto che sto eseguendo e vorrei sapere quali altri vantaggi può offrire.
Esiste un caso d'uso: Java SPI, interfaccia fornitore di servizi. Le interfacce sono fornite separatamente e le implementazioni (alternative) vengono fornite separatamente. Con una voce manifest con il nome dell'interfaccia, utilizzando un'interfaccia si può trovare tutto/qualsiasi provider di tale interfaccia. Mi vengono in mente le implementazioni Xalan e Xerces XML.
Anche senza SPI essere in grado di fornire diverse implementazioni, come un prototipo di Test Driven Development, può avere senso.
Giusto per offrire i miei 2 centesimi,
Attualmente sto lavorando ad un progetto C# che ha un progetto separato tenendo tutte le interfacce. Il progetto è stato denominato "framework" e faceva parte di un progetto più ampio comprendente oltre 10 implementazioni di interfacce da quel progetto quadro. La mia ipotesi era (che è poi confermata dal mio immediato superiore) che è separa completamente le implementazioni dal progetto, qualcosa chiamato loose coupling.
In questo modo diversi progetti che ereditano dal progetto quadro possono essere sviluppati separatamente o scambiati indipendentemente. Da uno sviluppatore che è nuovo al progetto, è più facile per lui/lei conoscere tutti i metodi utilizzati in altri progetti in un unico punto centrale. L'aggiunta di nuovi metodi o la rimozione di quelli vecchi vengono eseguiti in un unico progetto e ogni altro progetto che utilizza tali interfacce ha un rigoroso "contratto" da seguire. In sostanza aiuta a mantenere il progetto a lungo termine.
Inoltre semplifica la creazione di prototipi di alcune parti del framework durante il test, per isolare ogni classe singolarmente e verificarli per eventuali errori.
Si assiste nel rispetto del principio di segregazione di interfaccia in cui se una particolare interfaccia ha ad esempio solo un metodo di 'salvare', ma abbiamo bisogno di 'log' e 'leggere' per le classi di attuazione specifiche, possiamo semplicemente creare un'altra interfaccia che erediterà dall'interfaccia padre, il tutto nel progetto quadro, e non ci sarà più interesse nei diversi progetti per trovare l'interfaccia che vogliamo aggiungere. I found this durante la ricerca del principio di segregazione dell'interfaccia.
Rende le dipendenze più facili da gestire ed evita "accidentalmente" l'utilizzo di classi di implementazione che non si intende visualizzare. – biziclop
Immagino che si debba differenziare: basta lanciare qualsiasi interfaccia in uno speciale progetto di "interfaccia", non è giusto. Ma definire con cura i componenti per evitare dipendenze cicliche e migliorare i confini chiari è normalmente una buona cosa. – GhostCat
Correlati: http://stackoverflow.com/questions/1004980/should-interfaces-be-placed-in-a-separate-package – Maroun