java - 使用 OOP 和设计模式创建标准图形构建器

Question

这是我公司制作的带有连接表格的图表示例。

更新我的完整想法

自从我开始写这篇文章以来，我已经考虑了很多，我终于想出了一个想法，我认为使用 Builder 模式是可靠的我想告诉你们你们的想法以及你们认为我可能会遇到的问题碰到。首先让我解释一下完整的想法:

我的公司需要某种带有连接表的标准图，他们可以将其用于所有程序(这会让程序感觉它们都很相似(它们确实如此))因为这些图表中的大多数都是相似的我想我可以减轻每次您必须制作新程序或必须将图表放在其他地方时创建新图表的痛苦。

我的公司主要使用三种不同的图表:

• 条形图
• 折线图
• 饼图

创建这些图表时有一些未知变量。

• 图表系列的名称:这是将要显示的名称，与每个线/条/饼图切片不同

• 周期:图表数据取自某个时间段，一天或一周(周一、周二、周三等的每一天)一个月(一月、二月、三月、四月等)，甚至是一天。(晚上 8 点、晚上 9 点等)。

• 图表类型:当然，区别在于用户希望看到的图表类型。

最后但同样重要的是，图表创建之间的唯一区别在于饼图，饼图是 Javafx 中唯一不是从系列创建而是从 Observable 列表创建的图表，因此 pieChartBuilder 必须使用并插入以不同于其他方式的数据。

上图不是 UML 图，它是我如何规划我的新程序的行为和调整设计模式的演示，下面是我的想法的演练:

• GUI:首先，Gui 始终与实际逻辑分离，我没有计划要求 GUI 提供任何东西，除了它必须在 JavaFx 中创建并且它必须具有 Director 类的实例。

• Director:Director 类是所有操作发生的地方。首先，客户调用主管，告诉他他想要什么类型的图表，他想要什么时间段的数据，也许他想看什么样的数据。客户还可以设置他希望查看数据的时间段(日、周、月、年等)。

然后，Director 获取所有这些数据并对其统计类实例进行分类，要求该类提供数据，然后Director 可以将这些数据传递给图表构建器。

• 统计:统计类然后检查它是否已经包含数据，如果没有，它会为数据库的对象列表分类:

• 数据库:数据库非常简单，它为客户端发送的时间段内的数据分类(以天、周、月、年为基础)创建对象并将它们添加到一个列表并将其返回给统计类。

• (回到)统计类，然后计算对象数据并将其返回给主管。

• (回到导演中)导演现在调用 chartBuilder 来构建客户指定类型的图表，其中包含时间范围(时间数组或数组列表，这是客户可以选择的选项使用 Director.setStandardTime(time) 在 director 中设置)然后构建器使用从 Director 获得的数据创建图表和表格。然后，客户端可以调用 ChartBuilder.getChart() 并将其添加到他的布局中。

这是我的想法。我希望你能对此发表评论。感谢您的阅读，我期待着阅读您的所有回复。

Answer 1

图形任务最常见的设计模式是装饰器(通常带有 "fluent" interface )、原型(prototype)/克隆和访客。这些可能会派上用场。

Decorator :当你想递增地向你的对象添加属性时。如:

final int radius = 100;
// With fluent interface
final Graphic boxedShadedCircle = new Circle(radius, 100, 100).shaded().boxed();
// Without fluent interface
final Graphic nonFLuentBoxedShadedCircle = new Boxed(new Shaded(new Circle(radius, 100, 100)));

Prototype/Clone :当您希望能够复制某些对象时(复制/粘贴功能)。它基本上是可克隆接口(interface)。

Visitor :当您想向对象添加功能而不添加到实际对象中的代码时。比如说，如果您的应用程序以某种方式可编写脚本。有关示例，请参阅此帖子:Visitor pattern

现在与您的具体解决方案相关:

Decorator 似乎是实现您的第一个解决方案提案的好方法。或者 Template method或某种组合(“将通用图形绘制器与数据对象结合起来”)。

对于您的第二个解决方案，Factory似乎合适。

我不能说哪个最好。这取决于你本地的情况。所有实现都有利有弊，诀窍是在利大于弊的情况下选择合适的实现。

更新问题的更新:

ChartBuilder:这可能应该是设计模式 "Builder".此 dp 是关于以不同方式表示或呈现抽象描述/产品，例如文档描述或数据集。

导演:这是设计模式Mediator .或者 Facade ，取决于意图。如果您正在“隐藏”一堆蹩脚的遗留代码，则使用 Facade，如果您正在协调几个更现代的类的交互，则使用 Mediator。这里有很多灰色地带。如果 Director 还处理与 GUI 的交互(调整大小、隐藏等)，那肯定是 Mediator。

总体而言，您的结构是模型/查看器/ Controller 。 Director 充当 Controller ，Statistics 充当模型，chartBuilder 充当查看器。

多个设计模式重叠的情况并不少见，例如让 Controller 充当中介。

如果您使用设计模式将整个事情实现为请求/响应，您可能会更开心 Observer对于响应，而不是作为带有返回值的直接调用。这种方式更加灵活，您可以更好地隐藏线程中的延迟/计算/数据库查找。

您可能想使用 Composite对于图表生成器。如果您希望同时激活多个数据 View ，而不是一个 View 。