0

所以这个问题是从这里开始的（如何处理多个事件参数）。这个问题让我开始思考这个问题，但它的不同足以保证它自己的线程。

我正在创建一个游戏（出于娱乐和学习目的），并且想知道我是否使用了良好的设计标准。我想我可能已经在关注点分离上进行了 OTT，或者只是把整个事情弄错了，但我希望情况并非如此。重写它没有问题，因为我想学习“最佳实践”和它们的实际应用。

编辑

让我稍微解释一下这个游戏，它基于 Jawbreaker 一个在许多手机上发现的游戏（快速演示在这里找到）。目标是选择分组的球以将它们从比赛中移除并获得尽可能多的分数。

我正在尝试将其扩展一点，并使用不同类型的板，球以不同的方式移动，不同的球类型，球可能只是去他们被告知的地方，或者他们可能会沿途做一些事情。

所以这是我创建的对象的结构，第一行显示了 DLL 及其对象，第二行显示了这些对象引用的内容：

替代文字
（来源：ggpht.com）

这是我做 UML 的尝试：

替代文字 http://yuml.me/3279d2ac

单击此处链接到 UML 的完整页面，使其更大一些，希望更易于阅读

对象 DLL 包含游戏中使用的基本对象、球和棋盘。它们不包含任何关于它们如何对情况采取行动/反应的逻辑（球确实实现了 CompareTo 和 Equals 方法）。IBall 的实现可能有 X 个（对于 IBoard 也是如此，尽管我想象的不会那么多）。

InstanceManager DLL 被用作创建对象的一种方式，不确定这是 100% 需要的，它本可以在对象 DLL 中使用。工厂是具有各种重载方法来创建 IBall 对象的静态类。BallFactory 可以采用 BallType Enum、A Drawing.Color 对象等。 BoardFactory 非常相似。Jawbreaker 是一个单例对象，它处理诸如保存一个非常经常使用的随机对象和一些 GameConfiguration 数据（与本主题不太相关）之类的事情。

Engine DLL 是大部分工作发生的地方。LogicFactories 使用 BallType 和 BoardType 对象来创建相关的逻辑对象。逻辑对象用于控制 IBall 和 IBoard 对象的工作方式。BallLogic 告诉球在其事件触发时它可以做什么。例如，当一个球被选中时，会在 Ball Logic 上调用一个方法，说明板上 Y 上的 Ball X 已被选中。然后，球可以做任何它的类型的球应该/可以做的事情。BoardLogic 非常相似，它处理董事会的行为方式。

引擎对象是另一个单例，它是 GUI 与整个游戏交互的方式。GUI 不会直接实例化任何其他对象。

所以总结一下 IBall 和 IBoard 类只保存关于它们的数据，逻辑类处理所有功能。

我想知道的是：

1）这是一种明智的方法吗？

2）（通常）逻辑应该与对象/数据分开吗？

3）我是否在关注点分离方面走得太远了？

4) 关于设计/结构的任何其他意见

编辑

我使用几个单例的部分原因是为了简单地在一个地方访问数据而无需一直保持对象，也只是因为它是一个单一的游戏，不会扩展到高端或跨多台机器. 我确实知道它们不是很好，也不是我经常使用的东西，但感谢您的评论。

感谢您的想法和反馈。

4

2 回答 2

2

您的故障看起来正朝着正确的方向发展。但是，我不确定您是否尝试将演示文稿中的数据与逻辑分开。看看 MVC、观察者和策略模式。

请记住这一点：当您将应用程序设计为松散耦合时，需要进行权衡。您可以轻松地扩展应用程序，但会降低性能和内存使用量。另外，我讨厌这样说，但不要创建不必要的接口。如果您知道您现在或稍后将在创建接口时扩展对象的功能，如果在实现它之前不考虑它。

于 2009-12-17T17:15:56.767 回答
1

如果没有更好地了解您要做什么，就很难批评您的设计。我知道它涉及球和板，但除此之外，我不知道。

尽量避免单例。是的，我知道 GoF 书中列出了它，而且我知道这是一种常见的模式，但根据我的经验，它最终变成了一种反模式。

您提到 IBall 和 IBoard 没有关于它们如何交互的任何逻辑。这是否意味着他们没有任何方法？他们的方法只是他们私有数据的 getter 和 setter 吗？如果 IBall 和 IBoard 只是结构（或它们的等价物），那么它们不需要是接口。您能否充实您的描述，谈谈您可以发送到 IBall 和 IBoard 的消息类型？

2）（通常）逻辑应该与对象/数据分开吗？

有时。如果您有普通的旧数据，那么将逻辑与普通数据分开就可以了。当然，那么您就不再做 OOP 了——您正在编写过程代码。我认为您正在努力避免将任何行为硬编码到 Ball 中。也许其他实体应该负责决定球的交互方式，但您仍然有空间让 Ball 参与决策。这就是策略模式（以及其他模式）发挥作用的地方。想想现实世界中的事情是如何运作的——一个物理球和一个物理板如何协调它们的交互？如果他们互相交谈，他们会说什么？看看你是否可以在你的代码中实现它。

最后，谈谈设计。我认为想要“正确设计”是件好事。另一方面，这是成为一名建筑宇航员的道路。考虑一下您的代码库当前存在哪些问题。

  • 重构难吗？
  • 添加新类型的东西很难吗？
  • 是否太多“硬连线”？

设计并不存在于真空中——它受世界当前状态的影响。只要看看人们想出的一些疯狂的手机概念艺术，你就会看到糟糕设计的好例子。手机受到当前技术的限制，无视现实世界限制的设计无非是梦想。在软件中也是如此。注意代码告诉你它需要什么，你会做得很好。

您编写（和完成）的软件越多，您将拥有越多的经验，您的审美意识就会越好。不要让“做错”的恐惧阻止你完成你的软件。坚持下去，让它发挥作用，然后看看你从这个过程中学到了什么。

于 2009-12-17T19:56:37.310 回答