这个设计(反)模式的名称是什么?

what is the name of this design (anti-)pattern?

最近我接手了一个项目,最初是一个用 Swing 编写的胖客户端 Java 应用程序。后来他们得到了支持http请求的需求。所以他们实现了这样的代码:

public void handleRequest(...) {
    if(contextPath.equals("purchase-product")) {
        getMainPanel().getPurchasePanelButton().doClick();
        getMainPanel().getPurchasePanel().selectProductById(productId);
        if(getMainPanel().getPurchasePanel().getPurchaseButton().isEnabled()) {
           getMainPanel().getPurchasePanel().getPurchaseButton().doClick();
           ...
        }
    }
    ....
}

我的第一个想法是 WTF。他们不熟悉 MVC 模式吗?

但后来我想他们实现了这样的代码,以便能够使用 JMeter 或 SoapUI 通过 http 请求进行 Swing GUI 测试,而不是像 Squish 这样复杂的 GUI 框架。

我的问题是人们是否使用类似的技术来简化他们的组件测试?这个(反)模式的名称是什么?

我投票支持“Big Ball of Mud". Anyway it's clearly the opposite of the useful pattern "Tell, Don't Ask”,所有这些访问器 (get) 方法在每个可能的抽象级别公开实现细节。值得注意的是它无视得墨忒耳,在第二个参考文献中也提到了这一点。