Question

采用外观方法＆＃39;是不是设计不好？（我无法想到一个更好的术语）。例如：

public class MyService() {
    public void doThis() {
        // do something
    }

    public int doThat() {
       // do something
    }

    public boolean isThisTrue(String str) {
       // do something
    }

    // determine something by calling methods within the same class
    public boolean shouldSomethingBeDone() {
        int result = 0;            

        if (isThisTrue("foobar")) {
           doThis();
           result = doThat();
        }

        return result > 0; 
    }
}

我试图避免在我的一个调用服务的Controller类中有太多逻辑。我能看到解决这个问题的唯一方法是创建一个像上面那样的方法。

当我尝试创建单元测试并在shouldSomethingBeDone（）方法中模拟调用时，出现了这种困境。由于所有调用都是针对同一类中的方法，因此很难对此进行模拟。

感谢。

Answer 1

您是否看过Tell Don't Ask原则？

像isThisTrue这样的方法会提出问题并推动解决问题的逻辑。相反，更喜欢告诉对象该做什么，让它担心它。

这表明你应该重命名方法而不是shouldSomethingBeDone来告诉对象要做什么（没有真实姓名很难，但让我们说doSomething是一个更好的名字）。

Answer 2

在您提供的高度抽象化的版本中，很难说这是一个好的设计还是糟糕的设计的例子。但是，我不认为有一般原则说它很糟糕。

事情可能难以测试（详尽无遗）并不会使设计变得糟糕......或反之亦然。

我们可以批评这些方法的名称，但我不认为这可以解决您的问题，无论是设计还是可测试性。

Answer 3

使用方法构建代码通常是很好的设计。当然，你不应该过度创建大量的单行方法。

如果你有一个不应该被另一个班级调用的方法，那就不要使用public并使用private。

另一个优点：使用继承可能更容易，因为您可能不需要覆盖整个shouldSomethingBeDone()，而只是覆盖较小的方法。

是的，嘲笑很难。我会测试shouldSomethingBeDone()方法作为一个整体。或者只是使用Google来了解如何在您正在测试的同一个类中模拟方法。

是＆＃39;门面方法＆＃39; （调用自有类的公共方法）被认为是糟糕的设计？

3 个答案: