UML - 接口、抽象类或......？答案

【问题标题】：UML - interfaces, abstract classes or...?UML - 接口、抽象类或......？
【发布时间】：2012-11-06 08:27:31
【问题描述】：

我的程序有一些抽象的“模块”。假设它是一个 GUI 模块。它只包含模块的接口及其类型——为了与其他模块兼容（在另一个模块中，我可以使用 GUI 模块及其类型，而不用担心它的实现）。

所以我有这样的东西：

GUI::Component //represent the abstract component (button, label etc.)
//so it's only the base class for components

GUI::Clickable //if any component is clickable, it must inherit from it

GUI::Button : public Component, public Clickable
GUI::Label : public Component

但即使是 Label 或 Button 也只有虚拟方法（我猜它们是模块的接口）。 GUI 模块实现的例如SomeGUIImp 必须声明 SomeButton : public GUI::Button 和 SomeLabel : public GUI::Label（由于对象工厂，它们对用户来说是透明的）。

我不想更改代码中的任何内容，我只想为它制作一个合适的 UML 图。

所有元素 (Component, Clickable, Button) 都是接口吗？还是抽象类？

我想以某种方式表明Label 和Button 比Component 更“抽象”（用户可以更直接地使用，更具体）。

此外，最好能说明Clickable（它的功能）和Component（它是所有组件的抽象基础）之间的区别。

当前解决方案（不确定）

我不能说 100% 为什么，但在我看来，Clickable 可能是一个接口，Component 是一个抽象类，Button 只是普通类。

但这显示了模块内部的关系，忽略了Button（只有纯虚方法）也只是某些模块实现的声明？

【问题讨论】：

标签： interface uml virtual abstract class-diagram

【解决方案1】：

由于 C++ 没有接口的概念，当一个类是 100% 抽象（虚拟）时，您可以将其建模为接口或抽象类。在您的描述中，这些类在语义上更接近接口，因此以这种方式对它们进行建模会很好。恕我直言，您所采取的方向似乎非常好。

【讨论】：

【解决方案2】：

规则很简单——只有纯虚方法的类是接口，部分方法纯虚的类是抽象类，没有虚方法的类是实现类。如果这不适合您的设计，您可能应该重新考虑一些事情。例如，如果您将Button 视为接口和常规类，您可能应该将其拆分为 2 个不同的类 - 一个用于接口，一个用于实现。

【讨论】：