修改构造函数中其他对象的状态：design nono？

Question

我正在重构一些代码，发现了这个问题（当然是简化了，但总体思路是）：

class Variable:
    def __init__(self):
        self.__constraints = []

    def addConstraint(self, c):
        self.__constraints.append(c)

class Constraint:
    def __init__(self, variables):
        for v in variables:
            v.addConstraint(self)

约束的构造函数修改其他对象的状态而不是它自己的状态这一事实在我看来有点奇怪。其他人怎么看-这是可以的，还是重构的主要候选对象？你知道吗

Edit：我关心的不是父/子关系，而是它在构造函数内部链接，而不是在一个单独的方法中。你知道吗

Answer 1

我同意你的看法。这是倒退。可能有一些很好的原因，但它的编程不清楚，它可能会咬人，如果脚迟早。你知道吗

Answer 2

我认为这是一种自我注册模式。”你好，我是新来的，请允许我加入。”

我可能更喜欢有一个不同名称的方法，这样目的就更清楚了，但实际上我非常喜欢这种方法。你知道吗

Answer 3

我完全同意@djna的回答，即特定用例是完全合法的——这里，它是一个对象需要在“出生”时将自己注册到一组指定的注册中心的例子。你知道吗

它的一个非常尖锐且极为常见的子类是观察者对象，它的存在完全是为了观察一个给定的可观察物——非常好地将可观察物传递给观察者的初始值，以及确保类不变性的正确方法“这个观察者类的实例在任何时候都连接到一个观察者”，如果只在初始化完成后进行注册，则不会在“出生时”建立。你知道吗

其他类似的例子包括一个widget对象，它必须一直存在于一个容器窗口中：实现它会有点奇怪，除非widget将父对象作为初始值参数，并告诉父对象“嗨，我是你的新孩子！”。你知道吗

至少在这种情况下，您可以想象强制父对象或可观察对象拥有一个创建和注册新对象的方法。在许多类似这样的情况下，这种方法的本质是由内而外的——因为约束必须用多个变量注册，所以要求其中任何一个特定的变量来创建约束将是“违反规则的”。另一方面，您提供的代码非常自然。你知道吗

只有在不能合理地被框定为新对象“注册自身”的情况下，我才会感到一些怀疑（还有一些其他合法的，比如在出生时创建和注册其他辅助对象的对象，但它们远没有那么常见）。你知道吗