我应该分离模型类还是将它们作为一个单元？

Question

我的游戏逻辑模型由多个连接的类组成。有Board，Cell，Character等。Character可以Cell（1-1 rel）放置（移动）。

有两种方法：

1. 使每个类的模型实现接口，以便可以模拟它们，并且可以独立地测试每个类。它迫使我使每个类的实现不依赖于另一个类。但在实践中，很难避免Board过多地​​了解Cells并且Characters知道Cell存储机制是如何工作的。我有Character.Cell和Cell.CurrentCharacter属性。为了让setter正常工作（不是递归），他们应该依赖于彼此的实现。感觉模型逻辑应该被视为一个单元。
2. 让所有公共成员返回接口，但在里面使用精确的类（可能涉及一些向下转换）。这里的缺点是我应该将整个模型测试为单个模型，并且不能使用模拟来独立地测试不同的部分。此外，在模型中使用依赖注入是没有意义的，只能从控制器获得另一个完整的模型实现。

那该怎么办？

更新

您可以提出其他选择。

Answer 1

为什么这些只是两个选项？

如果您打算使用不同版本/类型的类，那么接口/抽象基类是强制执行共享行为和概括许多操作的好选择。然而，在没有彼此了解的情况下独立构建类的想法是荒谬的。 将类存储/行为分离到它所属的类/层总是一个好主意。例如。数据层中没有业务逻辑代码等，但是类需要彼此了解才能正常运行。如果您使所有内容独立并基于接口，则存在过度概括应用程序并降低效率的风险。 基本上如果你认为你需要将传入的对象转发到多种类型，那么最好先查看一下设计，看看你是否正在为性能损失和你要编写的令人讨厌的转换代码获得任何东西。如果你需要处理每种类型的downcast对象，你没有获得任何东西，使用多态性和基类是一个更好的方法。

使用接口不会消除测试中的麻烦。您仍然需要实例化某些版本的对象来测试单元/板上的大多数功能。对于完全回归测试，需要测试每个角色与两者的交互。

不要误解我的意思，你的角色类很可能有一个基类或有一个接口。所有角色都会（我敢肯定）分享很多动作并且可以从这个设计中受益。例如。在棋盘上移动角色是一种相当普通的操作，可以独立于角色，除了一些信息（例如角色如何移动，如果允许移动等），这应该是所述的一部分。基类/接口。

如果合理，可以单独设计类，以便可以自行测试，但不要将测试作为编写错误代码的理由。可以创建简单的存根或基本测试实例来帮助进行组件测试，并且比修复不必要的复杂代码花费更少的时间和精力。 接口有一个目的，但是如果你不同意处理2个类......那不是它。

*使用MVC也可以帮助您进行测试。如果操作正确，您应该可以换出任何图层，以便于测试单个图层。