java - Java 实现与 UML 规范关于接口(interface)和抽象类的区别

Question

存在各种类似的问题，但我找不到响应我的查询的问题。实现接口(interface)时具有指定聚合关系的可能性是我的问题的重要组成部分，其他类似问题或它们的问题中没有对此进行处理解决方案。

我的问题涉及 Java 中设计模式的实现。为了便于解释，我正在考虑如图所示的命令设计模式。

由于这个 UML 表示要求“Invoker”应该是一个接口(interface)，并且它还应该与“Command”接口(interface)具有 N 元聚合关系，因此如果我将 Invoker 定义为 Java 接口(interface)，则不可能实现它，因为我无法声明non-static non-final Java 接口(interface)中的属性，我确实需要定义 non-final Collection的“Command”对象来建立“Invoker”和“Command”之间的聚合关系。

所以，我继续将 Invoker 实现为抽象类，这让我可以进行聚合，并且还为“Invoker”的实现提供抽象，但我想知道这是否是一个好的设计实践，因为 UML 确实有一个刻板印象<<abstract>>但此模式的 UML 类图明确指定使用接口(interface)而不是抽象类。 出于类似的原因，我也对 Java 中“观察者”模式实现的“主题”接口(interface)执行了相同的操作。

请告诉我是否有一种方法可以将“Invoker”保留为Java中的接口(interface)，同时仍然实现具有指定重数的聚合关系。 如果我所做的是最好的方法，请告诉我它是否会对我使用这种模式构建的程序的结构产生一些不利影响。

在下面添加命令模式的简短 Java 实现的类图，我将其添加是为了提高问题的清晰度。我在这里将“ Controller ”配置为“调用者”接口(interface)，可以通过不同的方式实现，例如图中的“红外 Remote ”。但是“Invoker”和“Command”接口(interface)之间聚合关系的设计模式要求使我将“Controller”配置为抽象类，因为当我将“Controller”配置为接口(interface)时，我找不到任何方法来实现所需的多重性和关系。

Answer 1

命令模式中的重要部分是所有 ConcreteCommand我们有一个共同点Command “界面”隐藏了整个命令逻辑和所有可能的Receiver s。这会将一堆代码变成一个对象，任何人都可以执行，而无需了解系统的其余部分。这里重要的是依赖倒置原则方面的依赖方向。

我什至不会将此模式的实现作为实现Command的硬性要求。 “接口(interface)”，带有 interface 。关键是需要有一些东西来隐藏细节。如果您针对要在 Java 中实现的具体问题进行具体的 UML 系统设计，并将命令标记为 <<interface>>，那就是另一回事了。 .

Command之间的关系和Invoker也不是调用者“接口(interface)”(-contract)的真正一部分。客户不应该关心。它只是看到它可以传递命令。 n 元聚合的目的可能是表明调用者可以采用任何类型/数量的 Commands 。对或多或少超出该模式的事物的描述需要 Command s & 已知 Client (这种关系也不是必需的，命令可以以某种方式找到某些调用者比较 this 的方式)。该模式本身并不要求 Invoker是 interface 。它可以是具体的，因为具体的实现仍然有一个“接口(interface)”。

命令模式的一个常见应用是使用一个调用程序来跟踪所应用的命令并允许撤消它们。在这种情况下，具体调用者和命令之间存在很强的关系，其中调用者将命令存储在列表的某些 for 中。该图也可能意味着这一点。通常在模式图中根本没有这种关系。再次参见上面的链接。

无论这意味着什么，我都会说你不应该在 Command 之间实现具体的关系。和Invoker里面Invoker如果您决定制作 Invoker和interface 。这将超出该图所示的范围。它还将强制所有调用者具有特定的行为。这不是这个模式的重点。

<<interface>>和<<abstract>>仅当设计图表的人实际上意味着 Java 等效项时，构造型才有意义。当图表显示一个概念时，任何不相关的东西都将成为接口(interface)，情况通常并非如此。这同样适用于关系。 “聚合”的使用非常广泛。在调用者<>命令关系的情况下，这可能意味着调用者已经看到了所有命令，它不必存储它们。