2010-09-17 8 views
9

Sto scrivendo un'applicazione che crea un "catalogo" di file, che può essere attribuito con altri file di meta dati come allegati e miniature.Chi dovrebbe essere responsabile della chiusura di un flusso

Sto cercando di astrarre l'interfaccia in un catalogo al punto in cui un consumatore di un catalogo non ha bisogno di conoscere il file system sottostante utilizzato per archiviare i file. Quindi ho creato un'interfaccia chiamata IFileSystemAdaptor che è mostrata sotto.

public interface IFileSystemAdaptor:IDisposable 
{ 
    void WriteFileData(string fileName, Stream data); 
    Stream ReadFileData(string filename); 
    void DeleteFileData(string filename); 
    void ClearAllData(); 
    void WriteMetaFileData(string filename, string path, Stream data); 
    Stream ReadMetaFileData(string filename, string path); 
    void DeleteMetaFileData(string filename, string path); 
    void ClearMetaFilesData(string filename); 
} 

Essenzialmente la mia interfaccia IFileSystemAdaptor espone una semplice lista di file, che può anche essere associato ad altri file di dati di meta.

Come si può vedere, sto usando i riferimenti agli oggetti Stream generici per astrarre l'interfaccia ai dati di un file. In questo modo un'implementazione di un catalogo potrebbe restituire file da un disco rigido, mentre un altro potrebbe restituire i dati da un server web.

Ora sto cercando di capire come mantenere il mio programma di lasciare i flussi aperti. Esiste una regola empirica per quali membri dovrebbero chiudere i flussi? Se il consumatore di un flusso lo chiude, o il membro che ha creato il flusso originale deve essere responsabile della sua chiusura.

risposta

14

mie regole:

caso in cui il consumatore di un flusso di chiuderlo

  1. Se torno un flusso da un metodo, il consumatore è responsabile. Te lo sto dando, è la tua responsabilita '.

  2. Se accetto un flusso come parametro in un metodo, non lo chiudo. Quando si esce dal metodo, non so se il metodo di chiamata ne ha ancora bisogno. È il tuo stream, lo sto solo prendendo in prestito e non voglio rovinarti.

  3. Se creo uno stream e lo passo ad un altro metodo, il mio metodo lo chiude (o lo prova) quando ho finito. Non so che cosa ne farai, ma è il mio stream, quindi ne sono responsabile.

+0

Ottima risposta! Grazie! –

+0

Generalmente un buon insieme di regole, anche se aggiungerei un quarto: quando si accetta uno stream (o un altro 'IDisposable') in un costruttore o in un metodo factory, se l'oggetto costruito può sopravvivere a chiunque altro sappia del flusso incapsulato/oggetto, si dovrebbe fornire un'opzione * * affinché il metodo 'Dispose' dell'oggetto costruito disponga anche del flusso/oggetto incapsulato. – supercat

2

Il mio pensiero spontaneo in questo caso è che il consumatore dovrebbe avere la responsabilità di chiudere i flussi. Un IFileSystemAdaptor non può sapere quando l'utente ha finito di usare lo stream, quindi non può decidere quando chiuderlo.

1

In effetti l'ultimo oggetto che utilizza il flusso dovrebbe essere responsabile della chiusura, e generalmente è il chiamante.

Divertiti!

Problemi correlati