包装单个方法的方法

gin*_*boy 6 .net c# api coding-style

我想我生气了,有人请安慰我.

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);
    }
}
Run Code Online (Sandbox Code Playgroud)

人们继续在我们的代码库中添加如上所述的代码,肯定这是错误和可怕的,我通过删除它并用内部替换所有(或在这种情况下都是......)引用它来帮助世界码.

这种事情有没有真正的理由?我可以错过更大的图片吗?我们是相当YAGNI -centric我们的团队,这似乎在面部飞.我能理解这是否是更多的开始,但是这段代码已经蛰伏了很多个月,直到我今天绊倒它.我搜索的越多,我发现的越多.

Aar*_*ght 10

如上所述,类/方法是垃圾.但是,我可以看到可以合法使用类似模式的情况:

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 { ... }
Run Code Online (Sandbox Code Playgroud)

换句话说,如果您想支持不同类型的存储,那么您实际上可能会包装非常简单的方法以实现通用抽象.

但是,如上所述,该类没有实现任何接口,并且这些方法是静态的,因此它几乎没用.如果你试图支持上述模式,那么重构; 否则,摆脱它.

  • 这是一个更好的解决方法:D (2认同)

Jim*_*mmy 6

这是相当愚蠢的,直到你考虑隐藏这些方法的实现细节.

例如,如果您有这样的代码

File.WriteAllBytes(fileName, fileContents);
Run Code Online (Sandbox Code Playgroud)

分散在你的代码中,如果有一天你想改变你的应用程序编写文件的方法怎么办?那么在这种情况下,您将不得不遍历您的代码并更新所有这些代码行以采用新方法,与上述版本一样,您只需要在一个地方更改它.

我不是说他们的方式是正确的,你纠正它是错误的,我只是添加了一些观点

  • 担心不太可能发生的变化会污染代码库 - 这会让他们更难理解和维护. (2认同)
  • @Jeff:我同意对不太可能的改变的恐惧不应该是这样的事情的唯一动力,但这并不是隐藏方法背后的实现细节的唯一原因.`GetCustomerDataFileAsByteArray()`比`File.ReadAllBytes()`提供了更多的上下文,而且,恕我直言. (2认同)
  • @Seth:肯定有一个用于上下文,面向域的抽象的地方,但我认为它处于更高的层次,就像`GetCustomer(string sourceFilePath)`方法.然后*that*方法将直接处理优秀的,经过良好测试的.NET API,而不是处理不添加任何行为的外观,可能是未来错误的网站. (2认同)