我一直在研究和寻找答案，我怀疑可以通过更好地理解设计模式来解决这个问题。我认为问题在于我是一名自学成才的人，人们似乎倾向于熟悉许多深奥的术语;我最终在维基百科的螺旋上试图确定一些短语的含义。 这就是说 - 编码/结构问题。
实际上，在我开始之前，我应该指出，我可能会在我的问题中以代码的结构方式做出未知的假设。如果是这种情况，人们可以建议替代我的建议吗？我真的很感激学习如何更好地编写代码而不是简单地被告知我做错了。 OK ......
假设我们有一个Room类，它有4个墙，一个天花板和一个楼层。这些都在房间内“实例化”。房间还有一个桌子，里面有4个桌腿，再次在桌子内实例化，在房间内。 （我相信，这是作文，但如果我错了，请纠正我！）。
最后，问题： 如果有人以某种方式推动了桌子，那么TableLeg将需要检查他们所站立的地板类型以触发适当的声音。这，目前是我的解决方案：
表调度事件。 Room监听'table pushing'事件，查询Floor以确定其类型，然后将该类型传递给Table上的方法，然后将其传递给TableLegs。 对我来说，这看起来相当不优雅;因此我怀疑设计模式的知识可能是有用的。 对于我所描述的我不欣赏的结构，是否存在根本性的错误？如果是这样，有什么替代方案？
最后，我听说过“四人帮”一书。如果这是我的第一个停靠点，它是以可访问的方式编写还是我必须学习计算机科学来掌握它？ 很抱歉设计模式初学者的问题很长。
答案 0 :(得分：1)
地板可以侦听物体事件。事件界面可以显示有关对象几何体，材质等的信息。然后，地板可以检查碰撞并播放声音。
答案 1 :(得分：0)
我不知道我是否可以回答你的问题，但我可以告诉你一些关于“设计模式”的书。
这是1994/1995年出版时的经典之作。通过C ++和Smalltalk中的示例（当时没有Java或C＃），它列出了面向对象编程中26个常见问题的解决方案。它提供了一种记录力量和决议的格式，这种格式在多年之后被学术会议急切地抢购一空。很多程序员，包括我自己，都像圣书一样研究它，希望一本书可以让他们成为超级明星。
然后现实开始了。
功能程序员表示，这些模式是解决OOP缺陷的方法。大惊小怪的是什么？他们可以在不诉诸模式的情况下做这些事情。
一读这本书的通常反应就是尝试尽可能多地融入你当时正在编写的代码中的模式。
你会发现自己在设计会话中使用模式名称：“我认为我们需要一个责任链！”
最终你冷静下来，意识到模式不是你问题的答案。使用它们的最佳方式是仔细思考您的问题和解决方案，然后突然意识到您的答案恰好落入了一种模式。
至于你的问题，我认为你不需要一个模式。在生成声音之前，让Table向Floor发送消息以询问其类型。那就行了。简单是一种美德。