我们应该避免在不必要的时候使用spring管理的bean吗

Question

假设我有一个相对复杂的类，需要通过分解成几个较小的辅助类来简化它。一个建议的重构解决方案是：

public class RefactoredComplexClass {
    private final Helper1 h1;
    private final Helper2 h2;
    // Helper1 and Helper2 will be injected by spring IoC
    public RefactoredComplexClass(Helper1 h1, Helper2 h2) {
        this.h1 = h1; this.h2 = h2;
    }
} 
public class Helper1 {// no state class
    public int add(int x, int y) { return x + y ; }
}

上述建议背后的原因主要是为了让基于mockito的测试变得容易。

我的问题是：1.对于那些没有状态帮助程序的类，应该使用静态方法而不是实例方法吗？2.注入那些Helper对象是个好主意吗？

我自己认为应该使用静态方法，因为这些辅助类/方法没有状态可维护。并且注入那些助手类的实例是不必要的。但鉴于静态方法很难模拟，我同意上述解决方案使基于mockito的测试变得更容易。

有什么建议吗？

Answer 1

查看您的示例，静态方法似乎是可行的，即，如果您确信助手类将是绝对无状态的，并且您可以很好地测试静态方法，并且这些类中的所有方法都只是一堆实用方法。（例如java.lang.Math）

静态方法的一些注意事项：
1） 静态绑定和更好的性能。2） 无对象创建。3） 方法不能被重写4） 很难嘲笑5） 早期初始化

基于Spring的Singleton的注意事项（无状态助手最好是单例的，并注入到类中）
1） 你至少会有一个Object——你从继承、多态性等方面受益2） 可以延迟加载3） 易于模拟测试

您可以阅读这篇有用的文章

Answer 2

Hi^^您想更改/指定/提供不同的帮助吗？

如果是：

1：您使用的是访问者模式（实际上这里有帮助人员访问者）。。。这是一个很好的模式，即使它可能会产生很多类。它可以让你改变你的行为重构ComplexClass而不接触其代码，即使在运行时也是如此，并且太棒了。

相反，使用静态方法更简单，但要改变行为需要重写RefactoredComplexClass。

一般来说，我更喜欢合成而不是扩展。。。

2：这个主意一点也不坏。。。它允许您指定bahviour从Spring文件中选择您的类。

在其他情况下，保持简单确实是个好主意。