java - 在绘图应用程序中分离模型和 View / Controller

Question

我正在开发一个 vector 绘图应用程序(在 Java 中)，我正在为模型类和 View / Controller 类之间的分离而苦苦挣扎。

一些背景:

你可以绘制不同的形状:
矩形、直线和饼图

有 4 种工具可以用来操作 Canvas 上的形状:
缩放工具、移动工具、旋转工具和变形工具

对于这个问题，变形工具是最有趣的工具:它允许您通过拖动其中一个点并调整其他属性来更改形状，如下图所示:

这些转换规则对于每个形状都是不同的，我认为它们是模型业务逻辑的一部分，但在某种程度上它们需要暴露给 View / Controller (工具类)以便它们可以应用正确的。

此外，形状在内部通过不同的值表示: - 矩形存储为中心、宽度、高度、旋转 - 该线存储为起点和终点 - 饼图段存储为中心、半径、角度 1、角度 2

我计划在未来添加更多形状，例如星星、对话泡泡或箭头，每个形状都有自己的控制点。

我还计划在未来添加更多工具，例如旋转或缩放形状组。

每个工具的控制点不同。例如，使用缩放工具时，不能抓取中心点，而是每个缩放控制点需要关联一个轴心点(或多个轴心点供用户选择)。

对于像矩形、直线和饼图这样的简单形状，类的每个实例的控制点都是相同的，但是像贝塞尔曲线路径或星形(具有可配置的尖峰数)这样的 future 形状每个都有不同数量的控制点实例。

所以问题是什么是建模和实现这些控制点的好方法？

由于它们对于每个工具都略有不同，并且携带一些工具/ Controller 特定数据，因此它们在某种程度上属于工具/ Controller 。但由于它们也特定于每种类型的形状并带有非常重要的领域逻辑，因此它们也属于模型。

每当添加一个工具或形状时，我想避免为每个工具/形状组合添加特殊类型的控制点的组合爆炸。

---

更新:再举一个例子:在未来我可能会想到一个我想要支持的新形状:圆弧。它类似于饼图，但看起来有点不同，并且在拖动控制点时表现完全不同。

为了实现这一点，我希望能够创建一个实现我的 Shape 接口(interface)的 ArcShape 类并完成。

Answer 1

基本注意事项

为了简单起见，首先让我们做一些定义。

Entity 是一个领域模型对象，它定义了所有的结构和行为，即逻辑。EntityUI 是表示 UI 中的 Entity 的图形控件。

基本上，对于 Shape 类，我认为 ShapeUI 必须非常了解 Shape 的结构。该结构主要由我猜的控制点组成。换句话说，有了关于控制点的所有信息(将来可能是 vector )，ShapeUI 将能够在 UI 上绘制自己。

初步建议

我对 Shape 类的建议是，Shape 类定义所有行为。 ShapeUI 类将知道 Shape 类并保留对其所代表的一个引用，通过它可以访问控制点，并且能够操纵它们，例如设置他们的位置。 Observer 模式只是要求在此上下文中使用。特别地，Shape类可以实现Observable，ShapeUI将实现Observer并订阅相应的Shape 对象。

基本上在这种情况下会发生什么，ShapeUI 对象将处理所有 UI 操作，并将负责更新 Shape 参数，例如控制点位置。之后，一旦发生位置更新，Shape 对象就会在状态更改时执行其逻辑，然后盲目地(不知道 ShapeUI)通知 ShapeUI 关于更新状态。因此相应地 ShapeUI 将绘制新状态。在这里您将获得低耦合的模型和 View 。

至于Tools，我个人的看法是每个Tool都必须知道如何操作每种类型的Shape，即每个形状操作逻辑必须在 Tool 类中实现。对于 View 和模型的解耦，它与 Shape 几乎相同。 ToolUI类处理光标被点击的位置，点击了什么ShapeUI，点击了什么控制点等。通过获取这些信息，ToolUI 会将其传递给适当的 Tool 对象，然后该对象将根据接收到的参数应用逻辑。

处理不同的形状类型

现在谈到Tool 以它们自己的方式处理不同的Shape 时，我认为Abstract Factory 模式介入了。每个工具将实现一个抽象工厂，我们将为每种类型的Shape提供操作实现。

总结

根据我的建议，这是领域模型草案:

为了从我的建议中得到完整的想法，我还发布了特定用例的序列图:

使用 ToolUI，用户点击 ShapeUI 的 ControlPointUI