Design patterns 双向关联，什么'；更好吗？

这不是一个真正的问题，但是我想知道很多次如何在代码中实现双重关联

让我们举个例子。一个人的汽车只戴一顶帽子，帽子可以戴在一个人身上。但是如果这个人戴着帽子，帽子的主人一定就是那个人

以下是我过去的做法（Java）：

在性质上：

戴着帽子：

这样，男人的帽子和帽子的主人总是协调一致的

但是。。。这听起来有点笨拙。请问，实现这种条件设置器的更好方法是什么？这对我很有用

（如果我犯了错误，那只是因为法式面包好吗？^）

---

请向上^ ^

一些设计原则适用。封装意味着您不会让任何一个对象（帽子或人）处于不一致的状态。我认为你的解决方案正在实现这一点

第二个原理称为德米特定律，它通过减少耦合使软件维护更容易。它声明一个方法应该只使用

• 其类的实例字段
• 参数
• 使用

  new

其目的是使该方法避免要求另一个对象将其内部状态的一部分提供给它来处理。因为Hat有一个Man类型的实例字段，反之亦然，所以可能没那么糟糕

一个可以应用的设计模式（如果您想去掉冗余代码）可能是。这里是解决方案的一部分（您实际上可以只使用一个处理管理的类，而不必一直使用中介模式）：

缺点是

Man.setHat

和

Hat.setMan

都是公共方法，任何人都可以调用它们，而不必考虑您可以对中介程序进行编程的“全局”条件。例如，其他一些类可以在几个不同的

Man

对象上调用

setHat（h）

在这种情况下，您可以使用断言（契约式设计）来确保调用这些方法的任何人都不会违反所谓的不变量，例如，

Man.setHat（h）

的先决条件是

h.Man==null或h.Man==this

（它还没有被其他人佩戴）。然而，我不确定做这些事情是否比你当前的代码更笨拙

最后，您可以在不使用双向关联的情况下应用KISS原则。例如，如果一个

Hat

必须知道它在哪个

Man

上（可能不太可能发生），那么您可以实现一个

Hat.getMan（）

方法，该方法迭代已知的

Man

对象列表，搜索自身（或者如果担心内聚性，可以使用其他类为您找到它）。性能是您可能不想这样做的原因

---

一个相关的问题：

你为什么说它“笨拙”？请详细说明。谢谢你的回答。我想保持一个一致的模型，这个问题在我玩游戏时出现过很多次（一张牌必须知道它在哪个牌上，而牌必须知道它在什么牌上，等等）。这对我来说更清楚了。我只想问最后一个问题：双向联想是坏的吗？我问这个问题是因为令人惊讶的是，我没有在网上看到这个问题。在设计问题中，我避免问事情是好是坏。选择有后果。如果选择双向关联，则会产生这样的后果。

public void setHat (Hat hat) {
    Hat former = this.hat;
    this.hat = hat;
    if (former != null && former.getOwner() == this)
        former.setOwner(null);
    if (hat != null && hat.getOwner() != this)
        hat.setOwner (this);
}

public void setOwner (Character c) {
    Character former = this.owner;
    this.owner = c;
    if (former != null && former.getHat() == this)
        former.setHat(null);
    if (c != null && c.getHat() != this)
        c.setHat (this);
}