正如所写的那样，类/方法是垃圾。然而，我可以看到一种情况，在这种情况下，可以合法地使用 similar 模式：

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

字符串
换句话说，如果你想支持不同类型的存储，那么你可能实际上 Package 了非常简单的方法来实现一个通用的抽象。
但是，就像写的那样，这个类没有实现任何接口，而且方法是静态的，所以它几乎是无用的。如果你试图支持上面的模式，那么重构;否则，摆脱它。

这是相当愚蠢的，直到你考虑隐藏这些方法的实现细节。
举个例子，如果你有这样的代码，

File.WriteAllBytes(fileName, fileContents);

字符串
分散在你的代码中，如果有一天你想改变你的应用程序的写文件的方法呢？那么在这种情况下，你必须遍历你的代码，更新所有这些代码行来采用新的方法，就像上面的版本一样，你只需要在一个地方修改它。
我不是说他们的方式是正确的，你是错误的纠正它，我只是补充一些观点

这些方法的存在是一种令人厌恶的偏差，应该立即纠正。
它们可能是由不知道File类的人编写的，然后由知道的人重写，但没有你那么大胆。

如果所有的方法都接受相同的参数列表，并传递它们，那么不，这是毫无意义的，我认为实际上会使代码变得更难理解。然而，如果方法除了作为参数传递的值之外还传递默认值，或者对参数进行某种公共验证，那么这是一个更难的参数。
这些方法是否是以后要添加的逻辑的占位符？如果是，那么应该添加注解，甚至是可怕的TODO语句，以便稍后有人绕过去完成这个想法。

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

我想这个问题的答案取决于你的团队，实践和守则的最终目的是什么（例如，你发现的这段代码目前写入一个文件，但一旦完成，它将写入一个Web服务/数据库/莫尔斯电码机器-尽管这个“借口”有点被类/方法名称击败）。我想你已经回答了这个问题“我们很YAGNI-在我们的团队中处于中心地位，这似乎与之背道而驰。
不过，最终的答案是问写这篇文章的人为什么要这样写。