设计模式使组件可扩展，可插拔，而无需更改连接到的系统

Question

可以在此处使用哪些最佳设计模式来满足下面提到的业务要求？

让我们说我们有业务需求来创建一个可以轻松用于不同车辆的仪表板，例如汽车，船和飞机只需极少的更改，因此我们需要一个可以轻松定制的集中式界面，以便与底层系统进行双向通信（例如，收集有关速度，电池，深度，高度，热量和功能的信息，如转弯，加速，启动，停止，刹车等）。仪表板应附带仪表等与某事交谈，再次与底层硬件对话

明显的解决方案是将问题分解为组件（见下文），以便在切换车辆时需要进行最小的更改。在下面的解决方案中，只有CentralController的具体实现需要在每辆车上有所不同，但是如果您有需要在汽车中进行通信的组件，然后将所有这些类型映射到我们的Application相关类型，例如由Heat使用的HeatInfo HeatGauge可能包含来自内部，外部和来自引擎的信息，因此我们正在讨论车辆中的不同组件，并且每辆车可能有所不同，这里有哪些最佳实践来解决数据映射问题？

• 带仪表的面板
• CentralController {get / set}。 CentralControllerImpl
• 车辆及其组件

所以归结为：

有哪些设计模式可用于在多个复杂API之上创建简化API

---

由于你们有些人认为问题含糊不清，我会在这里发布真正的问题

我已经开发了一款应用程序，该应用程序可以控制非常复杂的硬件和平，控制各种传感器和控制器的存在，我正在开发的应用程序只暴露了一些相关人员角色的功能。

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

我想知道你们有哪些最好的设计模式可以用来创建易于使用和扩展的通用组件？

e.g。访客+ MVC是最明显的

Answer 1

您的要求对single pattern而言过于宽泛。虽然Visitor，MVC和Facade都可能在整体设计中发挥作用，但您正在描述一个更高，更复杂的系统。模式对于描述一系列常见行为和促进沟通很有用，但如果使用它们的方法是“我正在寻找一颗银弹”，那么这种努力将导致挫折和失望，因为模式会受到不应有的指责。

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

例如，

• 仪表板：使用 Facade 显示仪表的框架，前置控制器，为控件/仪表类型提供界面，可能 Blackboard 适用于需要协调仪表的情况
• Gauge：模块，以帮助提供组件框架，访问者，如果您需要通用回拨行为，观察者或如果您需要异步通信，则发布/订阅，如果显示元素需要随时间保持，则可以使用状态。

Answer 2

如果类在数据和行为上没有差异，为什么需要创建不同的类？也许会创造单一类：车辆？ 需求中没有复杂的问题，因此您似乎不需要模式。

Answer 3

我建议调查Builder设计模式并将其与Bridge相结合。