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 ; }
}

上述建议背后的原因主要是使基于模拟的测试变得容易。

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

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

有什么建议吗？

Answer 1

嗨^^您想更改/指定/给予不同的助手吗？

如果是这样的话：

1：您正在使用访客模式（帮助者实际上就在这里   访客）...这是一个很好的模式，即使它可能产生很多   类。它可以让你改变你的行为   RefactoredComplexClass，即使在运行时也不会触及其代码   那很棒。

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

总的来说，我更喜欢写作扩展......

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

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

Answer 2

看看你的例子，似乎静态方法将是要走的路，即如果你确定辅助类是绝对无状态的，你可以很好地测试静态方法，那些类中的所有方法都只是束实用方法。（例如java.lang.Math）

对静态方法的几点考虑：
1）静态绑定和更好的性能。 2）没有对象创建。 3）方法不能被覆盖 4）很难嘲笑 5）早期初始化

基于Spring的Singleton的注意事项（无状态助手最好是单身并注入你的班级）
1）您将至少拥有一个对象 - 您可以从继承，多态等中受益 2）可以懒洋洋地加载 3）易于模拟测试

您可以阅读此useful article

我们应该避免在不需要时使用spring managed bean吗？

2 个答案: