Dipendenze circolari rispetto a DRY

Question

Sto progettando una libreria di classi riutilizzabile che contiene 2 assembly (tra gli altri) denominati core.xml.dll e core.string.dll.

L'assembly xml fa riferimento all'assembly di stringhe per utilizzare alcuni metodi di stringa helper.

Tuttavia ora esiste un metodo di stringa che potrebbe trarre vantaggio dall'utilizzo di un metodo contenuto nell'assembly xml.

Se faccio riferimento all'assembly xml dall'assieme di stringhe, avrò creato una dipendenza circolare e non sarà possibile creare entrambi gli assembly dal codice sorgente. (cioè il problema del pollo e dell'uovo).

Per seguire il principio "Non ripetere se stessi", vorrei evitare di duplicare la funzionalità in entrambi gli assiemi. Se trovo un bug nell'implementazione, voglio solo sistemarlo in un posto.

Mentre potevo unire i gruppi in uno, questo non è l'ideale in quanto riduce la coesione dell'assieme.

Avrei bisogno di ricostruire e ridistribuire l'intero assieme solo per una piccola modifica a una classe specifica. Inoltre, alla fine, con così tante dipendenze probabilmente finirei con un enorme assemblaggio di librerie.

Quindi, nel contesto di un insieme riutilizzabile di gruppi di librerie qual è l'approccio migliore da utilizzare qui? Inoltre, in che modo lo stesso framework .NET si occupa di questo problema?

(riflettore sembra che fa riferimento a System.Configuration.dll System.xml.dll e viceversa. E 'questo in realtà corretta, se sì, come viene gestita la dipendenza circolare?)

Answer 1

Accetto con Coltelli. Le defezioni circolari sono un odore di design. Rifattalo senza pietà!

Questo può essere difficile nel caso in cui gli oggetti aziendali siano strettamente accoppiati. Nella maggior parte dei casi questo può essere risolto attraverso l'iniezione di dipendenza.

Pseudo C++ Esempio:

class Employee { 
    Company company; 
}; 

class Company { 
    vector<Employee> employees; 
}; 

Tricky? Non neccesarily:

template<class CompanyT> 
class Employee { 
    CompanyT company; 
}; 

class Company { 
    vector<Employee<Company> > employees; 
}; 

tipi più primitivi, che deve dipendere da un livello più alto, possono essere astratte di lavorare con qualsiasi tipo di altro tipo, a condizione che soddisfi i suoi contratti.

Answer 2

Suona come avete bisogno di un terzo assembly ...

Answer 3

Rendilo un metodo di estensione definito nell'assembly xml (basato sul tuo commento "metodo di conversione che accetta XML e converte in un formato basato su stringhe"). Si tratta di xml. Proprio come Linq fa per IEnumerable.

Answer 4

Se la libreria String richiede realmente la libreria XML, è probabilmente un'indicazione che la libreria String deve essere sottoposta a refactoring in una definizione di tipo di dati di livello inferiore e "utilità principali" (nessuna dipendenza esterna, se possibile) e un'altra libreria di livello superiore che può introdurre XML, SQL, espressioni regolari o qualsiasi altra cosa utile a livello di applicazione.