从孩子调用addChild（）？孩子加入自己？

Question

使用Actionscript 3.0中的显示列表，我经常倾向于让孩子将自己添加到他们的父母，因为他们通常已经有了这个引用。这将是这样的：

_myParent.addChild(this);

或移动时...

this.parent.removeChild(this);

通过addChild()语法的措辞，这种方式似乎倒退 - 顾名思义父应该是唯一一个调用该函数的人。

• 有没有其他人这样做？
• 或者这看起来倒退和混乱？
• 也许我正在陷入我不应该陷入的境地？

这似乎是一个违反职责因为父母应该是唯一一个呼吁自己的方法和负责自己的显示列表。

Answer 1

只要孩子提及其父母，你就会谨慎。虽然它没有违反与面向对象相关的任何规则，但它确实开始使您的结构更难于维护和理解。

ActionScript 3.0中的显示列表设计用于在与子级进行交互时使用方法调用，以及每当孩子做出可能对父级有趣的事情时发生的事件（有时冒泡）。

这个方向可以帮助我们让孩子们不知道他们在层次结构中的位置，并将它们设计得更像通用（可重用）组件。通常，ActionScript显示列表在从父到子移动时从更多到更不特定。例如，一个CreditCardForm可能包含一个TextInput控件。

Answer 2

虽然这不是一个好习惯，但this.parent.removeChild(this);有时很方便（取决于你的设计） - 我记得在AS编码的早期阶段就这么做了......然后我被告知它不是一个好的做法它和我不再使用它了。

关于_myParent.addChild(this); - 我通常不会将父对象传递给子构造函数/方法...我认为这种做法的根源在于AS2。是的，它看起来奇怪/令人困惑，因为它不是AS3的方式。

Answer 3

对我来说这似乎不好，因为父母的状态是它的状态，它打破了封装。

让我们想一个简单的情况，当你需要实现拖放。可以这样做：

1. 告诉孩子将他从他的父母中移除。然后告诉孩子将他添加到新的父母身上。父母甚至不知道这一点:-)。

2. 告诉家长 - 我需要你的孩子。他会移除那个孩子。然后告诉其他父母：从现在开始，这个孩子是你的。

   第二种方法似乎更合理的给我，因为如果你需要拒绝一些孩子（家长可以t have some types of children, or need to do some actions when you are getting new children, like prepare a bedroom, or buy some toys), you会是必须从你的子类调用了这一切。而这将需要显示你所有的父母s implementation for that. Sure it can be done via generic interface of parent, but I think it更加容易去此委托责任，父母和子女提供。每位家长都知道他应该做什么来添加这个孩子。

Answer 4

_myParent.addChild(this);

让我们打破这...

• _myParent
  这是对其他对象，这恰好是该对象的显示列表中的父级的引用。有一个对象引用其父对象的原因很多。他们在结构上密切相关，因此可能有理由相互沟通。因此，对显示列表父项的引用不是问题。

• addChild()
  调用其父公共方法之一不是问题。这是什么方法。如果这是父母的财产，那将是侵入性的。调用这个方法不会直接改变父对象的状态。家长将自行决定执行此功能。

• this
  事实上，这种情况下的论点恰好是自我指涉的，这是一个巧合。如果参数是一些微不足道的东西，比如new Shape()，那么它看起来不那么尴尬。但是，由于一个物体本质上是“增加自身”的，所以它看起来就像是一个由自己的靴子提升自己的人。但是，这不是现实生活;它是计算机编程，当它的语法读取时它是有意义的。

的Actionscript需要命名功能东西。把孩子带到显示列表上的另一种方法可能是addToParent()，当试图从父母中添加一个孩子时 - _myChild.addToParent(this)仍然会有相同的尴尬效果。

所以，虽然没有对象在这个尴尬的困境受到侵犯，有写addChild()语句更自然的方式，那就是从父母添加子，而不是周围的其他方法，因为这是奠定了订单由语法降低。所以，尽量使用自然的方式，当失败时，另一种方式仍然可以，只是有点尴尬。