4

可以在这里使用哪些最佳设计模式来解决下面提到的业务需求？

假设我们有一个业务需求来创建一个单一的仪表板，该仪表板可以轻松地用于不同的车辆，例如汽车、船和飞机，只需最少的更改，因此我们需要一个可以轻松定制的集中式界面，以便与底层系统（例如收集关于速度、电池、深度、高度、热量和功能的信息，如转弯、加速、启动、停止、刹车等）。仪表板应该带有仪表等，它们与再次与底层硬件对话的东西对话

显而易见的解决方案是将问题分解为组件（见下文），以便在切换车辆时只需进行最少的更改。在下面的解决方案中，只有 CentralController 的具体实现需要在每辆车上有所不同，但是如果您在汽车中有数百个要与之通信的组件，然后将所有这些类型映射到我们的应用程序相关类型，例如 HeatInfo 使用的HeatGauge 可能包含来自内部、外部和发动机的信息，因此我们正在讨论车辆中的不同组件，并且可能因车辆而异，在这里解决数据映射的最佳实践是什么？

  • 带仪表的面板
  • 中央控制器{获取/设置}。CentralControllerImpl
  • 车辆及其部件

所以归结为：

在多个复杂 API 之上创建简化 API 的设计模式是什么

由于你们中的一些人认为这个问题很模糊，我将在这里发布真正的问题

我开发了一个应用程序，该应用程序可以与控制数百种传感器和控件的非常复杂的硬件和平进行对话，我正在开发的应用程序仅公开了一些与负责该部分的某些人员角色相关的功能。

您应该看到硬件是一个非常复杂且您操作的大型信息数据库，而我正在处理的应用程序只公开了一点信息，但是这些信息可能需要读取数百个表并将所有这些信息编译到我的视图中相关域对象，实际执行映射的组件已被通用化，以便未来的应用程序可以利用它。

我想从你们那里知道什么是最好的设计模式，可以用来创建易于使用和扩展的通用组件（如果需要）？

eg Visitor + MVC 是最明显的

4

3 回答 3

2

您的要求对于单一模式来说太宽泛了。虽然 Visitor、MVC 和 Facade 都可能在整体设计中发挥作用，但您正在描述一个更高、更复杂的系统。模式对于描述一组常见行为和促进交流很有用，但如果使用它们的方法是“我正在寻找灵丹妙药”，那么这种努力将导致对模式承担不应有的责任感到沮丧和失望。

模块使用一组模式协同工作的设计如何更容易将单个元素集成到框架中，从而提供来自通用工具箱的组件的显示，然后针对正在实施的特定用例进行定制。您与仪表板的类比已被多次用作起点，因为它是一种有用的设计方法。

例如，

  • 仪表板：使用外观显示仪表的框架，前端控制器为控件/仪表类型提供接口，可能还有黑板 用于仪表需要协调的情况
  • Gauge：帮助提供组件框架的模块，如果需要通用回调行为，则为Visitor ，如果需要异步通信，则使用Observer或Publish/Subscribe ，如果显示元素需要保持一段时间，则可以使用State 。
于 2012-08-08T14:04:11.827 回答
1

如果类在数据和行为上没有差异，为什么需要创建不同的类？也许将足以创建单一类：车辆？需求没有复杂的问题，所以看起来你不需要模式。

于 2012-08-08T13:15:52.263 回答
0

我建议研究Builder设计模式并将其与Bridge结合起来。

于 2012-08-08T12:58:20.077 回答