哎呀。一对一的关系？使用什么模板？

你的推理中有几点我想评论一下。

在这里使用什么设计模式？

为什么在这里使用模板？

设计模式是一组旨在帮助解决常见问题的架构结构。它们不是强制使用的，你当然不需要尽可能地推它们。

也许掌握或固体？

或者也许是亲吻？这些精彩的字母组合当然很精彩，而且这些缩写背后的原理真的很不错。但在你的问题的背景下，它们听起来像是一个笑话“我擦了头灯，敲了敲方向盘，但汽车仍然无法启动。” 例如阅读罗伯特马丁，他很好地揭示了这些原则。

至于OOP（n - 设计）。尝试为天花板上的示例绘制类图是相当困难的，坦率地说，毫无意义。首先你需要决定要解决的任务，然后根据它们，限制模型，选择参与者，绘制和优化连接等。

您对问题陈述的主要问题 - “为了什么”？你在解决什么问题？

我将描述“车轮”的例子。比这样的方法（其中：汽车决定如何移动它，或者车轮决定汽车如何移动），对我个人来说似乎不合逻辑：

• 如果运动过程很复杂，而且依赖于其他机器的运动过程（或仅仅依赖于其他物体）——汽车的类别，或车轮的类别，必须包含大量的信息超出汽车/车轮本身的型号。为什么一辆车需要知道该地区的所有汽车？为什么轮子需要知道该区域中的所有对象？（凹坑，颠簸，石头和其他以一种或另一种方式影响运动轨迹的东西）。通常，这被认为是冗余信息，这种机器的类不能称为模型。（因为它不仅仅是一个模型）

例如，有一种奇妙的方法（MVC）提出将汽车及其车轮与移动过程分开。汽车只包含使它成为汽车的东西——发动机、车轮、方向盘和一堆汽车特有的元素，这些元素必须考虑到汽车在太空中的运动。

控制器（在我们的例子中，这是“物理学”，即根据汽车的当前状态、其元件、车轮、参数和车轮状态计算运动的东西），如有必要，可以了解这辆车所在的世界，并计算这个世界上所有机器的运动，从而考虑机器之间的相互作用。

在您的示例中：

汽车有轮子（包含），汽车给轮子旋转（影响），轮子移动汽车（影响）。

我不会让汽车有能力影响自己（或影响会改变汽车状态的车轮），因为这是一个整体架构，汽车本身无所不知。通过使用服务，您可以在物理框架内（将机器视为质点）和在动力学框架内（机器的每个元素都是机器的一部分）考虑机器的运动，因此机器是一个相互作用的粒子系统） - 你觉得可能计算的复杂程度如何增加？（这意味着架构的刚性降低了）