问Java纸牌游戏设计决策

EN

添加一个包含多个Table S的Stack类。

然后，每个堆栈都是一个卡片列表，您可以在其中取下最上面的一张，并在给定一些限制的情况下将一张卡片放在上面。

然后移动一张卡片(destination和source是Stacks)：

if(destination.canPut(source.top())){
    destination.put(source.take());
}

视图将知道在哪里以及如何渲染每个堆栈，以及卡片的外观等等。

那么最终的结果就是Card只是一个包含在堆栈中的不可变的哑对象。

使用多态性，每个堆栈可以有不同的约束，例如，大麻不能接受任何卡，结果只能接受相同的牌，更高的牌等等。

类应该处理它自己的位置吗？

不是的。正如您所说，卡的定义完全是由其级别和套间决定的。黑桃的10仍然是黑桃的10，不管它在哪里。事实上，我会争辩说，除了获得等级和西装之外，卡片没有其他相关的方法。(将equals和hashCode定义为方法是很方便的，但是如果您能够访问级别和适合，您可以比较卡片而不访问它们的私有字段。在排序时，不需要通过Comparators或诸如此类的东西就更简单了。如果你制作卡片，你可以免费得到这个。)

顺便提一下，这里有两个独立的立场概念。有与游戏逻辑相关的抽象逻辑位置(例如，黑桃的10位于左侧第4堆栈的顶部)，然后是表示位置(例如左侧的第4堆栈是在屏幕坐标58、160处绘制的)。堆栈的抽象位置属于模型，表示位置在视图中。

，这不意味着我的模型没有正确地解耦吗？

是的，如果在Card类中引入屏幕位置，就会引入从模型到视图的耦合。(从视图到模型，另一个方向的耦合是正常的。)例如，如果您想通过让3D卡在3D表周围移动来使游戏看起来更时尚，那么您必须更改Card类以包含3D点，而不是2D点。您不仅希望这样做，还可以通过将一个类替换为另一个类来更改视图实现--您还希望将模型与受视图设计更改影响的模型隔离开来。

如果视图应该处理卡的位置，那不是会产生过多的对象和引用吗？

我看不出卡的位置是如何从程序的一个层移动到另一个层，从而改变你必须跟踪的数据量。即使是这样，它也可能不会改变程序的渐近时间或空间使用。即使是这样，如果您没有明确定义的性能目标和可以对其进行基准测试的实现，那么担心优化还为时尚早。如果你做了非常非常错误的事情，一个拥有如此少的数据来追踪的游戏会有性能问题，这是值得怀疑的。