两个python类实例相互引用

我有两个python类，我们称它们为A和B。A负责通过网络接收和发送某种格式的消息。B负责信息的解释

现在a和b分别是类a和b的实例。考虑下面的场景：

• a接收消息并调用b的某个方法来解释消息
• b处理消息并希望使用a的某种方法发送响应

为了实现这一点，我构建了两个相互引用的类。这很好，但我想问你，这是否是一个设计缺陷，应该避免

有关说明，请参见以下最小代码示例：

class A:

    def set_b(self, b):
        self.b = b


class B:

    def set_a(self, a):
        self.a = a


if __name__ == '__main__':

    a = A()
    b = B()

    b.set_a(a)
    a.set_b(b)

---

CPython在一些版本之前添加了循环垃圾收集，因为循环依赖关系非常常见，这是一个问题。但是，如果使用调用

b

pass

self

方法的

a

方法，而不是依赖于

b

已经引用了

a

，则可能无法创建循环

如果你坚持这个循环，我会尽可能使联动装置自动。例如：

class B:
    def __init__(self, a):
        self.a = a
        a.set_b(self)

a = A()
b = B(a)
# Both instances are fully initialized and ready to go.

---

如果你忘记将

a

传递给

B

，你会立即得到一个异常。

很难说，把B作为一个单独的类并没有给meI带来太多的价值。meI同意@Sayse的说法，这并不是天生的错误，但我可能会重新思考你试图做的事情。将B作为a的子类（假设它没有在其他地方使用）可能更为有利。好吧，当我开始研究项目B时，我不必给出答案。我正在编写几个模块，A（即消息处理）始终保持不变，而B必须单独实现。这就是拥有两个类的最初原因。@BrandonM:也许我可以将它定义为一个子类。问题是我有一个抽象类（abc.ABCMeta），每个模块的B都是从这个抽象类派生的。这确保了每个模块的每个单独B类的结构保持不变。也许我必须研究多重继承。可以说，拆分类是有意义的。如果一方关心发送和接收信息，另一方关心做决定，那么将它们分开是完全好的。现在，我不再使用

set\u a

和

set\u b

，而是将它们重命名为

set\u sender

和

set\u message\u handler

。关键是你可以在不接触任何一个的情况下更换任何一个-这样做是有价值的，否则它只是设计过度。