问具有双向关系的类设计

EN

类设计中的双向关联是可能的，但它们总是要付出高昂的代价，你应该知道，而且必须愿意付出代价。

一般来说，我喜欢避免双向关联，唯一的例外是性能。正如您已经提到的，在不知道其他方向的情况下，您可能必须遍历所有其他对象以找到正确的对象(或者在您的情况下计算它们)。这可能是昂贵的，但它也可以通过其他方式，而不是建立双向关系(f.ex )。具有缓存的关联类)。

因为你很可能会得到数以百计的突触，在它们上循环来检查某些东西是否是可连接的是不好的，所以我认为你的双向关联可能是一个有效的选择。这取决于你对这场游戏到底是什么意思。

不会有太多人脉。

如果你能负担得起这个循环，那么我建议你这样做。如果您确实保持双向关系，您将不得不非常小心地保持您的模型一致。每次您触摸这些关联之一时，都必须确保以原子方式更新整个模型，使其再次保持一致。

很难确保所有涉及的对象/关联都正确地反映了每一个修改，但是一旦添加了并发性，它就会变得更加丑陋，因为您永远不希望另一个线程看到模型处于中间状态，在中间状态中只添加/删除了一个方向。

即使你使用像Hibernate这样的工具来支持双向关系，你也会得到其他的权衡。例如，如果将Hibernate与急切的获取相结合，那么无论何时只要调用一个join，您很可能最终都会从数据库读取整个神经网络。这都是要付出的代价的一部分。

还要注意的是，省略双向关系并添加一些帮助类来跟踪输入/输出的数量并不是个好主意。首先，您将一致更新模型的责任划分为主模型之外的内容，其次，需要添加任何一种方法来保持事物的一致性。您可能会接受糟糕的循环性能，或者您可以通过一些缓存的查找来合理地改进它，这些查找更容易更新，并且不一定是完整的。

概括地说:双向关系是可能的，但只有当你不能以一种可行的方式解决它们的缺位时，才应该考虑。