我正在重构一些代码，并且正在查看一个名为 HFile 的类。HFile 具有所有私有构造函数，因此您实际上无法创建它的实例。而不是创建 HFiles 的实例如下：
var file = new HFile('filename')
file.Save()
所有 HFile 交互都是通过静态方法处理的。因此，如果我想保存一个文件，我会调用：
HFile.save('filename')
然后在内部创建一个 HFile 实例，然后保存。显然，不了解整个故事的任何读者都必须保留判断力，但似乎使用静态方法在我的工作场所变得非常流行。所以我想知道是否有使用静态方法的良好原则/最佳实践可以帮助一群人坐下来回顾他们对静态方法的使用。
大量静态方法/静态类是过程炎的症状——用面向对象的语言编写过程代码。我所知道的消除这种思维的最好方法是彻底理解面向对象的原则和实践。使用测试驱动开发并强制代码可测试会有所帮助，因为为静态类编写测试要困难得多。最终，如果您使用 TDD，您自然会倾向于更解耦的 OO 架构，即使只是为了减轻测试的痛苦。
一般来说，如果您的情况需要封装状态或组织结构，那么您将使用类。
另一方面，如果您有一些横切关注点，并且可以在您的应用程序中广泛使用，您可能会考虑使用静态实用程序类中的方法。 System.Math在 .NET 框架（和 Java）中就是一个例子。
在您的示例中， HFile 可能是一个具有状态的对象，因此我通常不会使用静态方法来保存它。只需对特定的 HFile 对象进行方法调用就更简单了，而不必将整个对象传递给静态方法进行保存。这在您的特定应用程序中是否有意义取决于您的应用程序的范例是将 HFile 对象视为要传递并由外部方法执行的事物，还是能够自我保存的独立对象。
静态方法很难测试，因为您无法模拟它们。出于这个原因，我们倾向于在我的工作地点避开它们。尽管我们确实将它们用于工厂方法。
我不会像关心这些方法在做什么那样担心静态方法的数量。返回值或修改作为参数传递的对象的静态方法？没什么大不了的。修改私有静态字段的静态方法？我担心。修改属于其他类的公共静态字段的静态方法？我需要躺在一个黑暗的房间里，额头上有一块湿毛巾。
这不是非常面向对象的，是吗。现在，也许您所在的地方并不真正喜欢 OO 代码，这很好。但是如果你想封装数据和方法，那么你需要实例方法来处理这些数据。
大量的静态方法可能与许多全局变量相关联。例如。如果您要调用静态 HFile.save('filename')，您尝试保存到文件名中的信息必须是全局的。通常我们会尝试减少全局变量以使事情更易于管理。
但是如果你想写程序代码，那就没问题了。
IMO 静态方法对于您所描述的在您的工作场所很常见的目的没有用处。这种方法的缺点：
- 创建一个表示文件的对象以本质上只是在其上调用一个方法有什么意义？
- 不能使用基于接口的多态性
为了回答您的问题，在某些情况下我会使用静态方法：
- 一种实用方法，它执行与类功能相关的操作，但与任何一个对象无关。也许它需要一组对象并比较它们。也许它会进行一些通用的数据操作（转换等）。
- 你需要用类变量做与类相关的事情
- 你想要实现单例设计模式的地方