2010-09-17 73 views
9

我正在編寫一個應用程序來創建文件的「目錄」,這些文件可以歸因於其他元數據文件,例如附件和縮略圖。誰應該負責關閉流

我試圖抽象接口到目錄到一個目錄的使用者不需要知道用於存儲文件的底層文件系統的點。所以我創建了一個名爲IFileSystemAdaptor的界面,如下所示。

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); 
} 

基本上我IFileSystemAdaptor接口公開文件的平面列表中,也可以與其他元數據文件相關聯。

正如你所看到的,我使用了對通用Stream對象的引用來將接口抽象爲文件的數據。通過這種方式,目錄的一個實現可以從硬盤返回文件,而另一個實現可以從Web服務器返回數據。

現在我正試圖弄清楚如何讓我的程序保持打開狀態。有什麼成員應該關閉流的經驗法則?流的消費者應該關閉它,還是應該由原創流的成員負責關閉它。

回答

14

我的規則:

如果一個流的消費者將其關閉

  1. 如果我從一個方法返回一個流,對消費者負責。我把它交給你,這是你的責任。

  2. 如果我接受流作爲方法中的參數,我不關閉它。退出該方法時,我不知道調用方法是否仍然需要它。這是你的流,我只是借了它,而我不想把你搞砸。

  3. 如果我創建一個流並將其傳遞給另一個方法,那麼當我完成它時,我的方法會關閉它(或嘗試)。我不知道你會怎麼做,但它是我的流,所以我對它負責。

+0

最佳答案!謝謝! – 2010-09-17 21:59:38

+0

一般來說,雖然我會添加第四個規則:當在構造函數或工廠方法中接受流(或其他IDisposable)時,如果構造對象可能比其他實際知道封裝流/對象,應該提供一個*選項*以讓構造對象的Dispose方法也處理封裝的流/對象。 – supercat 2013-11-18 23:12:43

2

我在這種情況下的自發思想是,消費者應該承擔關閉流的責任。 IFileSystemAdaptor無法知道消費者何時完成使用流,因此它也無法確定何時關閉它。

1

實際上,使用流的最後一個對象應該負責關閉它,而這通常是調用者。

享受!