问题标签 [software-design]

我正在编写 XNA C# 中的俄罗斯方块克隆，我不确定在高层次上处理游戏数据结构方面的最佳方法。

我对碰撞检测、旋转、动画等非常满意。我需要知道存储“掉落块”的最佳方法——即不再受玩家控制的块。

我认为每个 Tetromino 块都应该存储在它自己的类中，该类由一个 4x4 数组组成，以便块可以轻松旋转。然后问题是我如何将 tetromino 的最终位置存储到游戏网格中，然后将 tetromino 切割成单独的块（对于每个单元格），然后设置主游戏网格的相应位置来保存这些相同的块，然后消失一次 tetromino它已到达最终位置。也许我的方法有一些缺点。

我应该为可以存储的主游戏网格创建一个 10x20 矩阵吗？或者我应该使用堆栈或队列以某种方式存储丢弃的块。或者也许有一些更好的方法/数据结构来存储东西？

我确信我的方法会奏效，但我正在伸出手来看看是否有人知道更好的方法，或者我的方法是否足够好？

PS 不是作业，这将是我的作品集的一个项目。谢谢。

我现在正在做的一件事与游戏有一些相似之处。出于说明的目的，我将使用一个虚构的假设游戏中的示例来解释我的问题。

让我们称之为DeathBlaster 4: The Deathening 吧。在 DB4 中，您有许多在移动时Ship会定期随机遇到的对象Phenomena。一个给定的在遇到它的时候Phenomenon可能有零个、一个或多个。例如，我们可能有四种和三种。EffectsShipShipsPhenomena

此外，Effects还可以相互交互。例如，GreenShip同时在 aGravityWell和 a中的 a 可能会在生成的和NebulaField之间产生某种协同作用。在这种情况下，协同效应本身就是一种——例如，这种相互作用可能会产生一种。除了作用于 a的集合之外，不需要任何信息来解决最终结果应该是什么。SpeedEffectShieldEffectEffectPowerLevelSynergyEffectEffectsShip

您可能会开始看到这里出现的问题。作为一种天真的第一方法，要么每个Ship人都必须知道如何处理每个人Phenomenon，要么每个Phenomenon人都必须知道每个人Ship。这显然是不可接受的，因此我们想将这些责任转移到其他地方。显然这里至少有一个外部类，可能是一个Mediator或Visitor某种。

但是最好的方法是什么？理想的解决方案可能具有以下属性：

• Ship添加一个新的就像添加一个新的一样容易Phenomenon。
• 不产生影响的交互是默认的，不需要额外的代码来表示。约定优于配置。
• 了解Effects彼此之间的交互方式，并能够管理这些交互以决定最终结果。

我想我已经决定了我的方法，但我很想听听最佳设计共识是什么。你会从哪里开始？你会探索哪些途径？

后续更新：谢谢大家的回复。这就是我最终要做的事情。我的主要观察是，相对于可能的×交互的数量，不同的数量Effects似乎很小。即，虽然有许多可能的交互组合，但这些交互的结果种类数量较少。PhenomenaShips

可以看到，比如表格中虽然有12种交互组合，但效果只有五种：速度修改、力量修改、护盾修改、无敌、死亡。

我引入了第三个类 ,InteractionResolver来确定交互的结果。它包含一个映射Ship-Phenomenon对的字典Effects（基本上是一个执行效果的委托和一些元数据）。当计算交互的结果完成时，每一个都会Ship被传递EffectStack给它正在经历的对应。Effects

Ships然后使用EffectStack来确定它们的实际结果，方法是Effects向它们现有的属性和属性添加修饰符。

我喜欢这个，因为：

• Ships 永远不需要知道Phenomena。
• Ship-关系的复杂性Phenomena被抽象为InteractionResolver.
• 如何解决多种可能复杂的效果的细节由InteractionResolver. 船只只需在必要时应用效果。
• 这可以进行其他有用的重构。例如，船舶处理效果的方式可以通过制作EffectProcessorStrategy. 默认可能是处理所有效果，但是，比如说，aBossShip可能会通过使用不同的EffectProcessorStrategy.

当然，大多数时候这种类型的请求来自管理层，他们既不知道用户真正想要什么，也不知道构建特定软件项目或一般软件的技术方面。有关更多详细信息，请参见呆伯特的尖头 Boss。

然而，这只是一方面。对您知道会损害您正在构建的系统的整体性能的项目的请求怎么办？或者，那些愚蠢地被赋予了权力，但他们所做的几乎所有事情都变成了傻瓜的技术白痴呢？（见这篇文章一个很棒的例子）

最终，你如何雄辩地、专业地、温和地处理对你正在构建的东西的要求或法令，你知道这些最终会损害项目？

欺骗：当客户要求一些可笑的事情并坚持

我有一个软件设计问题。假设我有一个包含一些元素的 Windows 窗体，并且我有一个客户对象。例如，客户可以是企业、私人或公司。

现在，表格中将要发生的所有决定都将取决于客户类型。例如，某些元素将被隐藏，某些标签文本会有所不同，等等......事件将有不同的响应。

显然，一种编码方式是在每次需要做出决定时使用 CASE 语句。另一种方法是从基类继承一个 Customer 类和 3 个其他类，例如 BusinessCustomer、PrivateCustomer 和 CorporateCustomer。在后者中，就会出现一个问题：您将如何将窗户合并到其中......

已编辑

我有一个想法：我可以在表单中嵌入表单吗？我的要求并没有规定同时显示两个窗口，所以我不必使用 MDI。但是为了根据这里的一些 ppl 评论简化我的设计，我想维护 3 个不同的客户表单，并动态嵌入到主表单中。这样，三个 GUI 是分开的，我不必处理每个控件的可见性。

我假设我可以将一个表单添加到另一个表单，例如：

UIKit 参考说 UIView 是 UIWindow 的超类，但尽管有这种父级，但 UIWindow 实际上管理 UIView。这对我来说听起来很不寻常。

有谁知道这在软件设计方面有什么意义？

非常感谢。

编辑：
我阅读了 iPhone 编程指南中的相关段落。然而我不明白为什么他们会反其道而行之：让 UIWindow 成为 UIView 的父级。一定有什么东西迫使 Apple 以这种方式设计类层次结构。

我需要创建一个原型来测试 WPF 执行以下操作的能力：

• 一个基础窗口作为应用程序的基础
• 在此窗口中，用户可以单击（例如“添加客户”）并弹出一个新窗口
  • 弹窗亮
  • 背景中的主窗口变暗
• 如果用户点击主窗口
  • 主窗口变亮
  • 弹出窗口变暗并进入后台
• 一个窗口中的任何更改，我们需要立即在所有窗口中生效，无论是明亮的还是暗淡的

问题：

1. 子窗口应该是用户控件还是窗口？
2. 有什么我可以利用的“MDI框架”吗
3. 是否有什么特别需要考虑以确保所有窗口都不断更新，例如使用 ObservableCollections 等？
4. 我应该将所有全局变量作为属性存储在主窗口中，以便子窗口可以访问它们吗？
5. 您将如何在 WPF 中“使窗口变暗”或“使窗口模糊”？

欢迎任何建议。

我有一个设计问题。当编写一个应用程序时，其中有几个组件共享某些属性，而其他组件在 GUI（Windows 窗体）和后端方面都不同，理论上如何解决这个问题？

例如，我有一个应用程序，其中有 4 种不同类型的产品。输入产品详细信息的表格都共享 3 个不同的字段。到目前为止，很容易 - 有一个基类，然后从这个基类派生 4 种形式。但是，比如说，2 种产品共享某种行为，这对它们来说都是相同的。当然，我可以有一个定义方法的接口，然后让这2个产品入口表单实现这个接口，但是由于接口没有提供默认实现，这样做岂不是很浪费？因为我必须在每个类中提供一个实现，如果它完全相同，那就是代码重复。

我当然可以将此方法放在基类中，并从中派生出 2 种形式。如果我的表单共享多个共同元素而不共享其他元素，那么在不必扯掉我的头发的情况下，最理智、最合乎逻辑的方式是什么？

我正在寻找一个可以帮助设计软件的图表程序，从高级需求到低级类和功能。

我见过很多 UML 程序，但它们不允许您在同一张地图中设计多个细节级别，就像您可以“放大”并设计零件的细节一样。

是否存在有助于这种设计的程序？让您在同一张地图上进行高级和低级设计的程序？

我正在考虑验证各种格式的实数的问题，因为这与我在设计中面临的问题非常相似。

实数可能有不同的格式组合，例如： 1. 前面有/没有符号 2. 有/没有小数点（如果没有小数点，那么可能可以事先约定小数位数） 3. 以 10 为底或以 16 为基数

我们需要考虑每个组合，所以有 2x2x2=8 个组合。您可以看到，随着每个新条件的施加，复杂性呈指数增长。

在 OO 设计中，您通常会为每种数字格式分配一个类（例如，在这种情况下，我们有 8 个类），并且每个类都有一个单独的验证函数。但是，对于每个新条件，您必须将所需的课程数量增加一倍，这很快就会变成一场噩梦。

在过程编程中，您使用 3 个标志（即 has_sign、has_decimal_point 和 number_base）来识别您正在验证的实数的属性。您有一个用于验证的函数。在那里，您将使用标志来控制其行为。

}

同样，复杂性很快就会失控，因为函数会被 if 语句和标志弄得杂乱无章。

我确信您之前遇到过这种性质的设计问题——许多独立的差异导致行为的差异。我很想知道您是如何在不使代码完全无法维护的情况下实现解决方案的。

像桥模式这样的东西会有帮助吗？

我正在开发一个员工目标 Web 应用程序。

领导/经理在与团队成员讨论后为他们设定目标。这是一年/半年/季度，具体取决于组织遵循的评估周期。

现在的问题是添加基于时间段的字段或存档上一季度/年度数据的更好方法。当用户想要查看以前的目标（不是那么频繁的活动）时，属于该日期的存档可能会在某个临时表中恢复并显示给员工。

开始的点

归档：减少数据库大小，导致更简单的数据库查询，当有人试图查看旧数据时会增加开销。

基于时间段的字段/表：查询中的一个或多个额外连接，以前的数据被视为与当前数据类似，因此在检索旧数据时没有开销。

PS：这不是空间成本，我的观点是我们是否可以在性能方面实现一些优化，因为这是一个网络应用程序，在高峰期组织中的所有员工都会查看/更新它。所以删除时间段使我的查询更简单。谢谢