0

我一直在研究并在这里寻找一个问题的答案,我怀疑这个问题可以通过更好地理解设计模式来解决。我认为问题在于我是一名自学成才的编码员,人们似乎倾向于假设熟悉许多深奥的术语;我最终陷入了维基百科的螺旋,试图确定某些短语的含义。就是说-关于编码/结构问题。

实际上,就在我开始之前,我应该指出,我很可能对我的问题中代码的结构方式做出了未知的假设。如果是这种情况,人们可以提出替代我建议的方法吗?我真的很感激学习如何更好地编码,而不是仅仅被告知我做错了。好的...

假设我们有一个 Room 类,它有 4 面墙、一个天花板和一个地板。这些是在房间“内部”实例化的。Room 也有一个 Table,它有 4 个 TableLeg,在 Room 内部的 Table 内部再次实例化。(我相信这是作文,但如果我错了,请纠正我!)。

最后,问题是:如果有人以某种方式推动桌子,TableLeg(s) 将需要检查他们站立的地板类型以触发适当的声音。这,目前将是我的解决方案:

表调度一个事件。Room 侦听“table push”事件,询问 Floor 以确定其类型,然后将该类型传递给 Table 上的方法,该方法又将其传递给 TableLegs。对我来说,这似乎相当不雅。因此我怀疑设计模式的知识可能有用。我所描述的结构是否存在一些我不欣赏的根本错误?如果是这样,有什么替代方案?

最后,我听说了《四人帮》这本书。如果这是我的第一个停靠港,它是以一种易于理解的风格编写的,还是我必须学习计算机科学才能掌握它?很抱歉,设计模式初学者的问题很长。

4

2 回答 2

1

楼层可以监听对象事件。Event 接口可以公开有关对象几何体、材质等的信息。然后,Floor 可以检查碰撞并播放声音。

我推荐这本书Head First Design Patterns

于 2013-02-14T11:47:18.967 回答
0

我不知道我是否能回答你的问题,但我可以告诉你一些关于“设计模式”这本书的事情。

它在 1994/1995 年出版时立即成为经典。通过 C++ 和 Smalltalk 中的示例(当时没有 Java 或 C#),它列出了面向对象编程中 26 个常见问题的解决方案。它提供了一种记录力量和决议的格式,多年来被学术会议热切地抢购一空。许多程序员,包括我自己,都在研究它,希望一本书可以让他们成为超级明星。

然后现实出现了。

函数式程序员说这些模式是针对 OOP 中的缺陷的变通方法。有什么大惊小怪的?他们可以在不诉诸模式的情况下做这些事情。

第一次阅读这本书的通常反应是尝试将尽可能多的模式融入到你当时正在编写的任何代码中。

您会发现自己在设计会话中使用模式名称:“我认为我们需要一个责任链!”

最终你冷静下来并意识到模式并不是你问题的答案。使用它们的最好方法是认真思考你的问题和解决方案,然后突然意识到你的答案恰好落入了一个模式。

至于你的问题,我认为你不需要模式。在生成声音之前,让 Table 向 Floor 发送消息询问其类型。这样就可以了。简单是一种美德。

于 2013-02-14T11:43:13.783 回答