当我们决定不变性时，我们应该看看现实世界吗？

Question

有一个强大的argument来使对象成为可变的。那么，在可能的情况下，我们是否应该始终保持不变性，或者在决定某些事物是否应该是不可变的时，先关注现实世界？

示例：纸牌游戏。 “卡片组”是不可改变的吗？我们有两个选择：

1. 甲板是不可变的。所有方法（shuffle，deal-one）都返回对新deck对象的引用。
2. 甲板是可变的。所有方法都会改变当前的牌组。

让甲板不变是很好的。我们将获得上述链接中描述的好处。但在现实世界中，一个套牌并不是一成不变的 - 我们随机播放并获得“同一套牌”，但顺序不同。

Answer 1

您应始终努力为您的方案做出最佳权衡。对于某种风格来说，没有任何意义，只是因为它很流行，或者是很酷的孩子或者正在做的事情。如果您已经听过支持和反对的论据，那么您应该能够权衡这两个选项并做出适合您，您的代码库和您的团队的决策。

警惕盲目遵循最佳做法。

---

就这个具有卡片组的特定情况而言，默认情况下我会倾向于不可变，但在我继续之前要问自己几个问题：

• 在一次洗牌/交易与下一次洗牌/交易之间是否存在足够的复杂性？ （如果是的话，+1表示不可变的，因为它可以“考虑到你的想法”，就可能引起的错误而言，如果你共享一个参考资料）
• 是跨线程共享的套牌的引用？ （如果是，+ 100表示​​不可变，因为如果你可以进行并发修改，复杂性会大大增加）
• 是否存在内存和/或速度限制？ （如果是，对于可变甲板+1，如果你真正资源受限，那么最有可能 - 但不能保证 - 修改甲板以提供更好的性能，并且一如既往地受到指导分析器）
• 是内存牌组必需以紧密映射到真实世界的牌组？例如。您的用户是否在他们自己的程序/ DSL中访问/查询它？ （如果是，可变性为+1，因为它可能更接近用户的心智模型。但是，这仍然是您选择的定义，并且不可变的套牌仍然有意义）

我担心这是一个狡猾的答案，但你总是要根据自己的情况来判断。有时设计匹配域比使对象不可变更重要。其他时候不是，并且在进行编程选择时值得忘记域名 - 请记住，您的域名很少需要关心或模拟我们程序员日常处理的很多事情。在其他具有其他限制的情况下，您可能只需要放弃它们！

Answer 2

不变性允许对象被视为一个值并被视为一个值。卡片是不可变形性的良好候选者，因为它不需要在之后进行修改。

请参阅此文章以帮助确定何时何地使用可变/不可变类IBM - Java theory and practice: To mutate or not to mutate?。