Question

我想我生气了，有人请你安慰我。

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为中心，这似乎在面对这一点。我能理解这是否是更多的开始，但是这段代码已经蛰伏了很多个月，直到我今天绊倒它。我搜索的越多，我找到的就越多。

Answer 1

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

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 { ... }

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

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

Answer 2

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

例如，如果你有这样的代码

File.WriteAllBytes(fileName, fileContents);

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

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

Answer 3

这些方法的存在是一种令人厌恶的失常，应该立即纠正。

他们可能是由一个不了解File课程的人编写的，然后被那些做过的人重写，但不像你那样大胆。

Answer 4

如果所有方法都采用相同的参数列表，并通过它们，那么不，它是毫无意义的，我认为实际上使代码 less 可以理解。但是，如果该方法除了作为参数传递的默认值之外还传递默认值，或者对参数进行某种常见验证，那么这是一个更难的参数。

这些方法的占位符是否可以添加以后的逻辑？如果是这样的话，那么应该添加注释甚至是可怕的TODO语句，以便稍后包围并完成思考。

Answer 5

我认为这些方法没有多大意义作为辅助类的静态方法，但该模式在某些情况下具有优点。例如：

将代码与静态类分离。如果MyFile不是静态的，那么它可以作为静态IO.File对象的抽象。直接访问文件系统的代码很难测试，因此这样的抽象可能很有用。（例如，我有一个IFileSystem接口，我的所有I / O代码都依赖于该接口，我的FileSystem类实现了这个接口并包装了File的基本方法。）
在方法中保持一致的抽象级别。我不喜欢将问题域中的代码（例如“customers”和“orders”）与_solution域中的代码混合在一起（文件和字节和位）。我经常会编写这样的包装器，以使代码更易于阅读并为我提供可扩展性。我宁愿阅读GetDataFileContents()而不是File.ReadAllBytes("foo.dat")。
提供上下文。如果正在为其副作用执行一段代码，例如删除文本文件以删除客户的订单，那么我更愿意阅读DeleteCustomerOrderFile("foo.txt")而不是File.Delete("foo.txt")。前者为代码提供了上下文信息，后者没有。

Answer 6

我想这个问题的答案取决于你的团队，实践以及最终目的的代码（例如，你发现的代码片段当前写入文件但会写入Web服务/数据库） / morse-code机器一旦完成 - 虽然“借口”有点被类/方法名称所击败）。我想你自己已经回答了这个问题：“我们的团队中我们非常以YAGNI为中心，而且这似乎也面临着这种情况。”

最终的答案是问问写作者，为什么他们这样写。

包装单个方法的方法

6 个答案: