包裝單一方法的方法

我想我會生氣，有人請讓我放心。包裝單一方法的方法

public class MyFile 
{ 
    public static byte[] ReadBinaryFile(string fileName) 
    { 
     return File.ReadAllBytes(fileName); 
    } 

    public static void WriteBinaryFile(string fileName, byte[] fileContents) 
    { 
     File.WriteAllBytes(fileName, fileContents); 
    } 
}

人繼續在我們的代碼庫將像上面的代碼，這肯定是錯誤的，可怕的，我刪除它，並更換所有做世界一個忙（或兩者在這種情況下... ）用內部代碼引用它。

這種事情有沒有真正的理由？我能否錯過更大的圖片？在我們的團隊中，我們相當於YAGNI，這看起來好像是在面對。我可以理解，如果這是更多東西的開始，但是這個代碼在很多個月中都處於休眠狀態，直到今天我絆倒它。我搜索的越多，我發現的越多。

來源

2010-02-24 gingerbreadboy

正如所寫，類/方法是垃圾。不過，我可以在其中看到一個類似模式可能被合法使用的情況：

public interface IFileStorage 
{ 
    byte[] ReadBinaryFile(string fileName); 
    void WriteBinaryFile(string fileName, byte[] fileContents); 
} 

public class LocalFileStorage : IFileStorage { ... } 

public class IsolatedFileStorage : IFileStorage { ... } 

public class DatabaseFileStorage : IFileStorage { ... }

換句話說，如果你想支持不同種類的存儲，那麼你實際上可能換以非常簡單的方法實現一個通用的抽象。

儘管如此，類沒有實現任何接口，而且方法是靜態的，所以它幾乎沒用。如果你試圖支持上述模式，那麼重構;否則，擺脫它。

來源

2010-02-24 14:31:33 Aaronaught

這是一個更好的方法去做：D – Jimmy 2010-02-24 14:34:23

有趣的想法，歡呼聲。 – gingerbreadboy 2010-02-24 14:41:44

這些方法的存在是一個令人厭惡的畸變，應該立即糾正。

他們可能是由不瞭解File課程的人編寫的，然後由某人做了改寫，但沒有像您那樣勇敢。

來源

2010-02-24 14:29:05 SLaks

如果我能你會得到兩票，一爲「令人厭惡像差」和一個「大膽」 :) – gingerbreadboy 2010-02-24 14:39:52

爲什麼這個downvoted？ – SLaks 2010-02-24 16:09:48

我想這個問題的答案取決於你的團隊，實踐和代碼ultiamte的目的是什麼（例如，你發現的代碼片段當前寫入文件，但將寫入一個Web服務/數據庫/摩爾斯碼機一旦完成 - 儘管這個「藉口」有點被類/方法名稱擊敗）。我認爲你自己已經回答了這個問題，「我們在我們的團隊中以YAGNI爲中心，這似乎是面對這個問題。」

雖然最終的答案是要求寫這篇文章的人爲什麼要這樣寫。

來源

2010-02-24 14:30:05 Rob

這是相當愚蠢的，直到你想到隱藏這些方法的實現細節。

舉個例子，如果你有這樣的

File.WriteAllBytes(fileName, fileContents);

遍佈你的代碼的代碼，如果有一天下來你想改變寫入文件出你的應用程序的方法行了？那麼在這種情況下，你將不得不遍歷你的代碼並更新所有這些代碼行來採用新的方法，與上面的版本一樣，你只需要在一個地方更改它。

我不是說他們的方式是正確的，你是錯的改正它，我只是增加了一些觀點

來源

2010-02-24 14:31:53 Jimmy

不可能發生的變化的恐懼會污染代碼庫 - 這會讓他們更難理解和維護。 – 2010-02-24 14:37:50

好點。如果我們需要在整個代碼庫中進行更改，那麼擁有一個寫入磁盤的集中點可以獲得回報。雖然我不認爲這是這裏的動機;） – gingerbreadboy 2010-02-24 14:39:11

我明白並同意，只是增加了我在這些開發人員心目中的數字 – Jimmy 2010-02-24 15:00:47

如果所有的方法做的就是採取相同的參數列表，並通過他們通過，則沒有，這是毫無意義的，我認爲實際上使代碼減少是可以理解的。但是，如果方法除了作爲參數傳遞參數之外還傳遞了默認值，或者對參數進行了某種常見驗證，那麼這是一個更難的參數。

這些方法佔位符爲以後的邏輯添加？如果是這樣，那麼應該添加評論或者甚至是可怕的TODO語句，以便稍後有人包裝並完成這個想法。

來源

2010-02-24 14:31:56 Nick

如果需要，默認值爲+1。 – 2010-02-24 14:52:33

我不認爲這些方法作爲幫助類的靜態方法很有意義，但該模式在某些情況下有優點。例如：

要從靜態類脫鉤代碼。如果MyFile不是靜態的，那麼它可以作爲靜態對象的抽象。直接訪問文件系統的代碼可能很難測試，所以這樣的抽象可能會很有用。（舉例來說，我有一個IFileSystem界面，所有的I/O代碼所依賴的，和我的FileSystem類實現此接口幷包裝的File的基本方法。）

要保留的方法抽象相一致的水平。我不喜歡將問題域（例如「customers」和「orders」）中的代碼與_solution域中的代碼（文件和字節和位）混合使用。我會經常編寫這樣的包裝，以使代碼更易於閱讀並提供可擴展性點。我寧願讀GetDataFileContents()比File.ReadAllBytes("foo.dat")。

提供背景。如果一段代碼正在執行其副作用，例如刪除文本文件以刪除客戶的訂單，那麼我寧願閱讀DeleteCustomerOrderFile("foo.txt")而不是File.Delete("foo.txt")。前者爲代碼提供上下文信息，後者則沒有。

來源

2010-02-24 15:00:07

第一點是我實際上想要在這個課堂上長期做的事情，以幫助測試/嘲笑等，但是今天的優先考慮並不是。 – gingerbreadboy 2010-02-24 15:55:05

包裝單一方法的方法

回答

相關問題