静态方法是 DI 反模式吗？
我是一名 Java 开发人员，开始掌握依赖注入的全部功能，我突然意识到没有办法注入静态方法。所以这让我开始思考：静态方法是 DI 反模式吗？
更重要的是：如果我要接受依赖注入，这是否意味着我需要停止编写静态方法？我之所以这么问，是因为没有办法在单元测试期间模拟它们并注入模拟静态数据，这对我来说是一个巨大的障碍。
编辑：我知道“包装”并注入现有静态方法的常见方法是这样的：
public class Foo {
public static void bar() { ... }
}
public interface FooWrapper {
public void bar();
}
public class FooWrapperImpl implements FooWrapper {
public void bar() {
return Foo.bar();
}
}
...但我不是问如何注入现有静态方法...我'我问我是否应该完全停止编写它们，如果我的所有代码（从现在开始）都将接受 DI 的概念。
另外，我看到很多与此类似的相关问题，但找不到提出同一问题的完全匹配的问题。如果您发现它确实是另一个问题的欺骗，请向我指出，我将亲自关闭这个问题（请不要只是关闭投票！）。
I am a Java developer who is beginning to grasp the full power of dependency injections, and it suddenly dawned on me that there's no way to inject a static method. So it got me thinking: are static methods DI anti-patterns?
More importantly: if I were to embrace dependency injection, does this mean I need to stop coding static methods? I ask because there is no way to mock them and inject mock statics during unit tests, which is a huge turn-off for me.
Edit: I know that a common way to "wrap" and inject an existing static method is like this:
public class Foo {
public static void bar() { ... }
}
public interface FooWrapper {
public void bar();
}
public class FooWrapperImpl implements FooWrapper {
public void bar() {
return Foo.bar();
}
}
...but I'm not asking how to inject an existing static method...I'm asking if I should stop writing them altogether, if all my code (from this point forward) is going to embrace the notion of DI.
Also, I see a lot of similarly-related questions to this, but couldn't find an exact match that asked this same question. If you see that it is indeed a dupe of another question, please point it out to me and I will close this question myself (please don't just closevote it!).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
静态方法适用于没有关联状态的事物。一些工厂方法、“纯函数”方法（如 Math.sin 等）都是完全可以接受的静态方法方法。
java.lang.Math和java.util.Collections有许多完全可接受的静态方法的优秀示例。幸运的是，这些方法不需要依赖注入，或者与这些东西交互；它们的测试并不异常困难。他们没有需要模拟或任何东西的依赖关系。
另一方面，静态或具有相关静态状态的静态方法是完全邪恶的。这是一种反模式。
当且仅当它总是在等效输入上返回等效输出时，它通常有助于将方法定义为无状态（因此是合法的静态方法）。这清楚地表明，例如数据库查询和文件系统 I/O 使方法具有状态，因为它们的输出将根据文件系统或数据库中的内容而变化。
Static methods are appropriate for things that don't have associated state. Some factory methods, "purely functional" methods like
Math.sin, and the like are all perfectly acceptable static methods.java.lang.Mathandjava.util.Collectionshave many fine examples of perfectly acceptable static methods.Fortunately, these methods have no need for dependency injection, or to interact with such things; they're not unusually difficult to test. They don't have dependencies that would need mocking or anything.
On the other hand, static state, or static methods with associated static state, are utterly evil. That is an anti-pattern.
It frequently helps to define a method as being non-stateful (and therefore a legitimate static method) if, and only if, it always returns equivalent output on equivalent inputs. This makes it clear that e.g. database queries and filesystem I/O makes methods stateful, because their outputs will vary depending on what's in the filesystem or the database.
重要的静态方法不与依赖注入兼容。只需将它们设为单例的实例方法即可。
Non-trivial static methods are not compatible with dependency injection. Simply make them instance methods of singletons.
我将你的问题改写为“当我使用依赖注入时，如何区分 java 方法何时应该是静态的，何时不应该是静态的？”
在我看来，区分不应该纯粹根据是否有状态来进行，而应该根据您是否想在测试中模拟该方法来进行。
我知道像 Mockito 这样的较新的 BDD 测试框架完全能够模拟静态方法，但这样做会带来显着的性能成本。
I'll rephrase your question as "How do I distinguish between when a java method should be static and when it shouldn't, when I am using dependency injection?"
In my opinion distinction should not be done purely based on whether is stateful or not, but rather whether you might want to mock the method in a test or not.
I am aware that newer BDD testing framworks like Mockito are fully capable of mocking static methods, but doing so comes at significant performance cost.