Come risolvere le dipendenze del pacchetto circolare

Naviga le tue risposte
8

Sto rifattorizzando un grande codebase in cui la maggior parte delle classi si trova in un unico pacchetto. Per una migliore modularità, sto creando sotto-pacchetti per ogni funzionalità.

Ricordo di aver appreso da qualche parte che un grafico di dipendenza del pacchetto non dovrebbe avere cicli, ma non so come risolvere il seguente problema: Figure è nel pacchetto figure , Layout è nel pacchetto layout , Layout richiede che la figura esegua il layout, quindi il pacchetto layout dipende dal pacchetto figure . D'altro canto, un Figure può contenere al suo interno altri Figure s, con il proprio Layout , che rende il pacchetto figure dipendente dal pacchetto layout .

Tuttavia ho alcune soluzioni, come creare un'interfaccia Container che Figure implementa e inserirla nel pacchetto Layout . Questa è una buona soluzione? Altre possibilità?

Grazie

    
posta vainolo 13.02.2013 - 07:36
fonte

2 risposte

6

Dovresti pensare a Inversion of Control

Fondamentalmente definisci un'interfaccia per il tuo Layout che si trova da qualche parte vicino alla tua classe di layout in un proprio pacchetto, quindi avresti un pacchetto di implementazione e un pacchetto di interfaccia pubblica - per esempio chiamalo Layoutable (non lo faccio sapere se è inglese corretto). Ora - Layout non implementerà quell'interfaccia ma la classe Figure . Allo stesso modo crei un'interfaccia per la figura che è Drawable per esempio.

Quindi 

my.public.package.Layoutable
my.implementation.package.Layout
my.public.package.Drawable
my.implementation.package.Figure

Ora - Figura implementa Layoutable e quindi può essere utilizzato da Layout e (non sono ancora sicuro se questo è ciò che volevi) - Impaginazioni di layout Drawable e può essere disegnato in una figura. Il punto è che la classe che espone alcuni servizi lo rende disponibile tramite un'interfaccia (qui: Layout e Layoutable) - la classe che vuole usare quel servizio deve implementare l'interfaccia.

Allora avresti qualcosa come un oggetto creatore che si lega entrambi. Quindi il creatore avrebbe una dipendenza da Layout e Figure , ma Layout e Figure sarebbero indipendenti.

Questa è l'idea approssimativa.

Una fonte eccellente di soluzioni a questi problemi è il libro Java Application Architecture di Kirk Knoernschild.

    
risposta data 13.02.2013 - 11:12
fonte
0

Non sono molto chiaro su cosa sia Figure , ma forse dovrebbe essere nello stesso pacchetto di Layout ?

La tua soluzione di interfaccia Container proposta non funzionerebbe, a meno che tu non abbia inserito l'interfaccia Container in un terzo pacchetto, avresti comunque una dipendenza circolare tra i due pacchetti. Vedi la risposta di michael_s per qualcosa che potrebbe funzionare.

Un'altra cosa, come altri hanno menzionato, probabilmente non sarà mai un problema. In futuro ti imbatterai in problemi solo se Figure e Layout vorranno essere in moduli separati. Puoi occupartene se e quando ciò diventa necessario, ma dato che le due classi sembrano strettamente correlate, sembra altamente improbabile.

    
risposta data 13.02.2013 - 11:31
fonte

Leggi altre domande sui tag

Tipi in Lisp e Scheme Come mantenere un repository git biforcato con feature branch che upstream non tirerà?