A quale spazio dei nomi appartiene una classe di fabbrica?

Ho una classe di fabbrica, DocumentLoaderFactory, che restituisce semplicemente un'istanza che implementa un'interfaccia, IDocumentLoader.A quale spazio dei nomi appartiene una classe di fabbrica?

Tutto applicazione risiede con la seguente spazio dei nomi

Skim.Ssms.AddIn.ActiveFileExplorer.Loader

Ma quello che mi chiedo è, che fa spazio dei nomi DocumentLoaderFactory appartiene? Per ora ho inserito la classe factory sotto lo spazio dei nomi *.Loader, ma viene utilizzato da un controllo utente (ActiveFileWindow) dello spazio dei nomi principale, Skim.Ssms.AddIn.ActiveFileExplorer come illustrato di seguito.

Quali sarebbero i pro & sv di collocare il metodo di fabbrica entro *.Loader o il suo spazio dei nomi padre? Vorrei prendere una decisione a seconda dei pro/contro dello.

Ecco il layout del mio progetto alt text

fonte

2009-08-24 Sung

Direi il suo meglio per unire le vostre fabbriche con i tipi che creano. Una fabbrica è un fornitore di qualcosa e dovrebbe essere associata e vicina alle cose che fornisce. Se segui le regole della coesione, verrai alla stessa conclusione. Le cose correlate dovrebbero essere vicine per mantenere un'API coesa.

fonte

2009-08-24 00:30:51 jrista

@jrista: ho deciso di lasciare la classe factory all'interno dello spazio dei nomi di Loader. Avere il metodo factory nello spazio dei nomi genitore sembra inquinare la struttura del progetto. – Sung

Penso che sia il posto giusto.:) Se si decide di estrarre lo spazio dei nomi Loader nel proprio assembly, non si avranno problemi con i riferimenti mancanti di fabbrica o qualcosa del genere. – jrista

direi lasciarlo in **. * Loader namespace in quanto renderà più facile trovare quando si lavora con il tuo IDocumentLoader implementazioni .

fonte

2009-08-24 00:28:12

Per quanto ne so, in genere un oggetto non deve chiamare/creare un'istanza di un oggetto/metodo dello spazio dei nomi figlio. Ma se dovessi spostare la fabbrica nello spazio dei nomi genitore, il metodo factory non sarebbe l'unico ad accedere alle classi all'interno dello spazio dei nomi figlio? – Sung

Perché lo diresti. Non vedo un motivo per cui un oggetto non possa chiamare/istanziare e metodo/oggetto di uno spazio dei nomi figlio. Dipende davvero da come vuoi che la tua API guardi dall'esterno. –

Poiché il codice che utilizza le esigenze di fabbrica non ha alcuna conoscenza dell'implementazione nel modello di fabbrica astratto, di solito inserisco l'interfaccia e la fabbrica (più qualsiasi tipo di informazione) nella radice, quindi le implementazioni nelle proprie cartelle (o cartella se ce ne sono pochi).

Quindi nel tuo caso ho qualcosa di simile:

Loader 
- DocumentLoaderFactory 
- DocumentLoadType 
- IDocumentLoader 


Loader\Implementation 
- NameDocumentLoader 
- TypeDocumentLoader 
- ConnectionDocumentLoader 
- DocumentLoader

ho pensato che DocumentLoader è una classe base astratta che eredita l'interfaccia a causa del suo nome, ma si ottiene l'idea. Non so cosa sia l'altra classe "TreeViewImageIndex" ma potresti metterla in un posto o in un posto completamente diverso se appropriato.

Ciò mantiene il codice piacevole e coeso, non richiede la classe di implementazione per conoscere lo spazio dei nomi Loader \ Implementation e consente di semplificare la lettura della struttura del documento.

fonte

2009-08-24 01:09:15 Odd

@Odd: Grazie, dispari. Sì, DocumentLoader è una classe * abstract *. E creare un altro spazio dei nomi per l'implementazione è un approccio che non ho pensato a – Sung

@Odd: L'astrazione introducendo un altro spazio dei nomi è solido, ma avere uno spazio dei nomi troppo profondo nel mio caso non sembra valere la pena per il mio caso specifico. – Sung

Va bene, non è adatto a tutti. Personalmente non mi piace tenere troppe lezioni in un singolo spazio dei nomi/directory perché ingombra il mio codice e dove posso logicamente separare, lo faccio. – Odd

A quale spazio dei nomi appartiene una classe di fabbrica?

risposta

Problemi correlati