将不同操作委托给不同类的设计模式

Question

我有一个 ABC 类，它可以执行操作 a()、b() 和 c()（操作 == 方法），它们都密切相关。我也有类似的 DE 和 FGH 类。将来，可能会添加带有其他操作的新类。类从不共享操作（例如，没有类 ADF）

我的程序应该能够执行所有这些操作，而且时间是“随机的”，这意味着我事先没有估计什么时候/多少次执行哪个操作。

我通过创建一个包装类“OperationInvoker”来处理这个程序。我的程序只能访问此调用程序，并且每个操作都有一个方法。这样做的好处是封装：如果创建了新操作或现有操作或编辑了新操作，则只有包装类需要编辑。

我的问题是“巨大的”包装器是否是解决这个问题的最佳模式？

我为此研究了观察者模式，我认为这不是一个合适的案例，因为 ABC、DE、FGH 类......从来没有任何共同利益。比如，如果需要执行操作 A，所有注册的类都会收到事件 A，只有 1 个类（即 ABC）会对这个事件真正感兴趣。所有其他注册的类都将丢弃该事件。这似乎是所有注册和观察的过度杀伤/开销。

委托模式也遇到了同样的问题：我没有很多类以不同的方式执行相同的操作，因此拥有灵活的委托系统毫无意义。

还有其他更好的模式吗，或者这只是拥有委托包装类的简单案例？

编辑：有人问 ABC 到底是做什么的。好吧，我有一个描述 SOAP Web 服务的 WSDL 文件。我使用一个工具将此文件转换为 java 类。这意味着我无法控制这些类的内容，因为它们是自动生成的。所以我写了一个类 WebServiceInvoker 作为这些 Web 服务的包装器。这个包装类有 3 个方法：做 Web 服务 A、做 Web 服务 B 和做 Web 服务 C。

随着程序的扩展，越来越多的wsdl文件进入画面。当然，没有一个 Web 服务做同样的事情。它们没有全部捆绑在一个大 wsdl 文件中的唯一原因是因为某些 Web 服务在逻辑上不属于其他 Web 服务。所以我结束了以下课程：

• 一个可以调用Web服务A、B和C的封装类
• 一个可以调用Web服务D、E的封装类
• 一个可以调用webservice F、G、H的封装类

将来可能会出现更多 wsdl（以及包装类）。之所以在所有其他包装器周围有一个附加包装器，是因为每个服务都需要使用“会话 ID”来调用。所以每个包装器都需要知道这些信息。所以 superwrapper 持有这些信息，并且可以调用所有的 web 服务。这也作为一个 api 工作得很好：使用 Web 服务的程序对服务一无所知，它只有一个通过超级包装器可用于每个 Web 服务的公共方法。该程序当然知道每个 Web 服务返回什么（一个列表、一个字符串、什么都没有……）。

Answer 1

为了便于代码维护，我建议将包装器更改为如下内容：

public class Operations {
    private ABC abcInst;
    private DE deInst;
    private FGH fghInst;

    protected Operations(ABC abc, DE de, FGH fgh) {
        this.abcInst = abc;
        this.deInst = de;
        this.fghInst = fgh;
    }

    public ABC getABC() { return abcInst; }
    public DE getDE() { return deInst; }
    public FGH getFGH() { return fghInst; }
}

这种方式在这里不需要维护（除非添加了一个新类），并且来自调用者的所有调用只需要额外的.getABC().a() 而不是.a() 等。这强调了执行操作的事实通过不同的类，但仍然允许通过传递 Operations-instance 来访问所有功能。

Answer 2

看起来你在一侧有一个明确的架构，你试图不泄露到其他组件中。避免此类泄漏的自然方法是增加一层分离度。

基本上，如果您愿意，您仍然可以保留一个巨大的包装器，但您需要考虑您希望公开的内容并仅公开它。看起来您想要公开的只是一个已知操作的列表，所以如何：

// Your setup - trimmed down.
interface ABC {

    public void a();

    public void b();

    public void c();
}

interface DE {

    public void d();

    public void e();
}

interface FGH {

    public void f();

    public void g();

    public void h();
}

// Your current wrapper.
class AllOps {

    public ABC getABC() {
        return null;
    }

    public DE getDE() {
        return null;
    }

    public FGH getFGH() {
        return null;
    }
}

// One further degree of separation.
enum Op {

    A {

                @Override
                void op() {
                    ops.getABC().a();
                }

            },
    B {

                @Override
                void op() {
                    ops.getABC().b();
                }

            },
    C {

                @Override
                void op() {
                    ops.getABC().c();
                }

            },
    D {

                @Override
                void op() {
                    ops.getDE().d();
                }

            },
    E {

                @Override
                void op() {
                    ops.getDE().e();
                }

            },
    F {

                @Override
                void op() {
                    ops.getFGH().f();
                }

            },
    G {

                @Override
                void op() {
                    ops.getFGH().g();
                }

            },
    H {

                @Override
                void op() {
                    ops.getFGH().h();
                }

            };
    // Hide the huge wrapper.
    private static AllOps ops = new AllOps();
    // Only expose the operations.
    abstract void op();
}

public void test() {
    Op.A.op();
    Op.F.op();
}

不确定这是什么模式，但如果您只公开枚举，我认为您已经实现了断开连接。

可以以任何您喜欢的方式将其他操作添加为实现op 的新枚举。他们甚至可能不使用巨大的包装器。