'外观方法'（调用自己类的公共方法）是否被认为是糟糕的设计？

Question

拥有“外观方法”是否被认为是糟糕的设计（我想不出更好的术语）。示例：

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 来了解如何在您正在测试的同一类中模拟方法。