我们应该避免在不必要的时候使用spring managed bean吗？答案

【问题标题】：should we avoid to use spring managed bean when it is unnecessary?我们应该避免在不必要的时候使用spring managed bean吗？
【发布时间】：2015-03-04 00:06:10
【问题描述】：

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

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 的测试更容易，因为静态方法很难模拟。

有什么建议吗？

【问题讨论】：

将操作的管理者/用户与操作（帮助）类分离似乎是个好主意。您说这些操作实例没有状态，但这是您的实现的选择。我可以很容易地想象出许多场景，您将实例化具有相应状态的多个版本。

标签： java spring refactoring mockito static-methods

【解决方案1】：

看看你的例子，静态方法似乎是要走的路，也就是说，如果你确定帮助类绝对是无状态的，你可以很好地测试静态方法并且这些类中的所有方法都是一堆实用方法。（例如 java.lang.Math）

静态方法的一些注意事项：
1）静态绑定和更好的性能。 2) 不创建对象。 3) 方法不能被覆盖 4) 难以模拟 5) 早期初始化

基于 Spring 的单例的注意事项（无状态助手最好制作为单例并注入到您的类中）
1）你至少有一个对象——你从继承、多态等中受益 2) 可以懒加载 3）易于模拟测试

你可以阅读这个useful article

【讨论】：

【解决方案2】：

嗨 ^^ 你想改变/指定/给不同的助手吗？

如果是这样：

1：您正在使用访问者模式（助手实际上在这里访问者）......这是一个很好的模式，即使它可能会产生很多类。它让你改变你的行为 RefactoredComplexClass 无需接触其代码，即使在运行时，以及太好了。

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

总的来说，我更喜欢组合而不是扩展...

2：这根本不是一个坏主意......它让你指定bahviour 来自 Spring 文件的类。

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

【讨论】：