Registrazione di un errore e creazione di un errore quando la registrazione fallisce creare una dipendenza circolare tra due progetti

Question

Registrazione di un errore e creazione di un errore quando la registrazione fallisce creare una dipendenza circolare tra due progetti

#1 da (3 voti)

4

Come parte di un programma che sto sviluppando per scopi pratici, ho creato uno spazio dei nomi Core progettato per contenere le risorse del codice di base per il programma da utilizzare. Questo spazio dei nomi si trova in un progetto Libreria di classi.

Due degli spazi dei nomi secondari in Core sono Core.Files e Core.Errors . In Core.Files c'è una classe TxtFile che è responsabile per l'input-output in file .txt. In Core.Errors esiste una classe Error che è responsabile della gestione di un errore specifico. La classe API ti consente di gestire un errore in tre modi:

Mostra l'errore all'utente.
Registra l'errore in un file di registro.
Esegui entrambi.

Nelle ultime due opzioni, Error dipende da TxtFile per registrare l'errore nel file di registro (utilizzando il metodo Write() ).

Il metodo Write() in TxtFile è costruito in modo tale che se non riesce a scrivere il testo nel file, viene creata un'istanza di Error . Poiché ovviamente qualcosa non funziona in Write() , l'errore viene visualizzato all'utente ma non ha effettuato l'accesso al file.

Tutto funziona alla grande. Nel corso del tempo, tuttavia, i due spazi dei nomi sono cresciuti e ho pensato che sarebbe stato opportuno creare un progetto separato per ciascuno di essi.

Il problema è che poiché Error dipende da TxtFile e TxtFile dipende da Error , esiste una dipendenza circolare tra i due progetti ed è impossibile aggiungere riferimenti tra di loro.

Questa risposta suggerisce che una tale situazione è un'indicazione di cattivo design. Come posso migliorare il design in modo che questo problema non si verifichi? Voglio conservare la struttura di un singolo assembly per sottospazio.

Grazie.

design circular-dependency

posta Sipo 19.05.2017 - 14:59

fonte

1 risposta

Leggi altre domande sui tag design circular-dependency

Modellazione del dominio di gestione dei contenuti Modelli di progettazione per l'elaborazione / la manipolazione dei dati

score 3 · Answer 1

Se non sei interessato a ridisegnare il modello a oggetti, il seguente cambiamento (abbastanza comune) ti farà andare di nuovo.

Avvia una nuova libreria di classi chiamata Interfaces o qualcosa di simile.
In entrambi i progetti esistenti, aggiungi un riferimento a Interfaces .
Nella nuova libreria, definisci un'interfaccia IError e ITxtFile che corrispondono ai metodi e alle proprietà necessari di entrambe le classi da entrambe le librerie.
Modifica le due librerie esistenti in modo che Error e TxtFile implementino le interfacce appena create.
Scrivi factory per TxtFile e Error . Non devono essere fantasiosi.
Modifica il costruttore per Error in modo che richieda un TxtFileFactory come argomento del costruttore. Utilizza la factory per creare TxtFile (invece della parola chiave new ).
Modifica il costruttore per TxtFile in modo che richieda un ErrorFactory come argomento del costruttore. Utilizza la factory per creare Error (invece della parola chiave new ).
Aggiungi TxtFileFactory e ErrorFactory al tuo contenitore di iniezione delle dipendenze.
Modifica il tuo codice in modo che lavori solo con le interfacce, non con i tipi concreti.

Spiegazione: nessuno dei due progetti dipenderà dall'altro per la creazione dell'oggetto. Invece, otterranno i loro riferimenti da una fabbrica che viene iniettata. Poiché il grafico dell'oggetto è definito nella radice di composizione, viene eliminata la necessità di una dipendenza circolare per la creazione dell'oggetto e, a causa delle interfacce definite nella terza libreria, non esiste più alcuna dipendenza di interfaccia circolare.