无状态对象的静态类的替代方案答案

【问题标题】：Alternative to static class for stateless objects无状态对象的静态类的替代方案
【发布时间】：2010-11-12 06:13:07
【问题描述】：

在过去一年左右的时间里，我一直遵循这样的想法，即如果一个方法可以是静态的，就让它成为静态的，因为这可以带来性能优势，因此我最终在我的应用程序中使用了一些静态类。

从那以后，我了解到性能优势通常不够大，不值得，而且可以将方法设为静态的区别，也许不应该从设计的角度来看，如果它们更具体到对象，而不是类型 - related question

例如，我最近创建了一个 FileRepository 类，它为我们自己的 File 类（例如导入文件）实现了存储库模式。这个类不是静态的，必须先创建一个repository对象才能访问它。

我的问题是我所有的旧静态调用，现在都是 2 行（除非我可以在本地范围内重新使用该对象）。存储库对象（目前）没有状态，因为它通过线程静态变量使用数据库访问。

我的问题是，人们对在类上拥有一个线程静态 Current 属性有何看法，get 访问器在第一次调用时在哪里初始化对象？据我了解，这仍然可以避免静态类的陷阱，例如无法通过接口实现通用功能，但仍然可以轻松地对存储库对象进行单行调用？

只是试图调整自己的做法和心态，让自己变得更好。

【问题讨论】：

切线：FileRepository 不应该是无状态的。 FileRepository 应该明确依赖于数据库。 IE。它的构造函数应该使用一个数据库（并将其存储到一个成员变量中）。如果没有状态，FileRepository 就会对它所拥有的依赖项撒谎。这使得编写测试变得困难，因为你不能只给它一个模拟数据库；您已经建立了一个真实的数据库并让它使用它。为测试设置一个真实的数据库不仅很麻烦，而且可能会使您的测试变慢。你为什么讨厌未来的自己：P

【解决方案1】：

静态往往会损害可测试性。

特别是，您会发现测试任何使用存储库的东西都相对困难。而不是在每次调用时创建一个 new 存储库，它应该是任何需要它的状态的一部分。使用依赖注入来提供实现适当接口的存储库。然后，您可以通过模拟它来测试任何使用存储库的东西。

当然，这是一个理想主义的解决方案，对于您的情况可能不是实用的解决方案 - 但它通常是面向对象的解决方案。

您可以拥有“当前”存储库并且仍然可以合理地测试，但它仍然需要静态状态，这通常是不受欢迎的。有点代码味道，但至少会比静态方法好。

【讨论】：

【解决方案2】：

不使用静态的东西并始终保持对依赖项的直接引用的一个好处是能够轻松地模拟和单元测试对象。如果您直接引用静态类或当前属性，您将失去此能力。

【讨论】：

【解决方案3】：

您需要解释您所说的性能下降类型。我们说的是微秒吗？

通常情况下，可以通过运行分析器并查找有问题的代码来提高应用程序性能。以 ANTS profiler 为例。

我经常发现数据库访问在 70% 的情况下都是罪魁祸首。

【讨论】：