使用Actionscript 3.0中的显示列表,我经常倾向于让孩子将自己添加到他们的父母,因为他们通常已经有了这个参考。那看起来像是:
_myParent.addChild(this);
或删除时......
this.parent.removeChild(this);
根据addChild()
语法的措辞,这种方式似乎是倒退 - 名称表明父应该是唯一一个调用该函数的人。
似乎是违反职责,因为父母应该是唯一一个调用自己的方法并负责自己的显示的人列表。
答案 0 :(得分:1)
每当孩子提到父母时,你都要小心谨慎。虽然它不会破坏与面向对象相关的任何规则,但它确实会使您的Composite结构更难以维护和理解。
ActionScript 3.0中的“显示列表”旨在在与子项交互时使用方法调用,并在子项执行父项可能感兴趣的操作时使用事件(有时冒泡)。
这个方向有助于我们让孩子们不了解自己在层次结构中的位置,并将它们设计得更像通用(可重用)组件。通常,ActionScript显示列表在从父级移动到子级时会从更多特定的位置移动到更不具体的位置。例如,CreditCardForm可能包含TextInput控件。
答案 1 :(得分:0)
虽然这不是一个好习惯,this.parent.removeChild(this);
有时很方便(取决于你的设计) - 而且我记得在AS编码的早期这样做...然后我被告知这不是一个好的做它的方式,我不再使用它。
关于_myParent.addChild(this);
- 我通常不会将父对象传递给子的构造函数/方法......我认为这种做法的根源在于AS2。是的,它看起来很奇怪/混乱,因为它不是AS3方式。
答案 2 :(得分:0)
这对我来说似乎很糟糕,因为父级的状态是s children. So by having reference to child you can change parent
状态,它打破了封装。
当你需要实现拖放时,让我们想一个简单的例子。它可以这样做:
告诉孩子将他从父母那里移走。然后告诉孩子将他添加到新的父母。父母甚至都不知道: - )。
告诉父母 - 我需要你的孩子。他将移除那个孩子。然后告诉其他父母:从现在起这个孩子就是你的。
第二种方式对我来说似乎更合理,因为如果你需要拒绝一些孩子(父母可以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
必须从你的孩子班级中调用所有这些。这将需要显示你所有的父母{{ 1}}更容易将这个责任委托给父母并提供孩子。每个家长都会知道他应该做些什么来添加这个孩子。
答案 3 :(得分:0)
<强> _myParent.addChild(this);
强>
让我们打破这个......
_myParent
这是对另一个对象的引用,该对象恰好是显示列表中对象的父对象。对象有很多原因可以引用其父对象。它们在结构上密切相关,因此很可能有相互沟通的理由。因此,引用父母显示列表不是问题。
addChild()
调用父母的公共方法之一不是问题。这就是方法的用途。如果这是父母的财产,那将是侵入性的。调用此方法不会直接改变父级的状态。家长将自行决定执行此功能。
this
这种情况下的论证恰好是自我指涉的事实是巧合。如果论证是微不足道的,例如new Shape()
,那就不那么尴尬了。但是,由于一个物体基本上是“自我添加”,它似乎就像一个人通过他/她的自我提升自己。但是,这不是现实生活;它是计算机编程,当通过语法阅读时它是有意义的。
Actionscript需要将函数命名为 something 。让孩子进入显示列表的另一个选择可能是addToParent()
,当尝试从父母_myChild.addToParent(this)
添加孩子时,这仍然具有相同的尴尬效果。
所以,虽然在这种尴尬的困境中没有违反任何对象,但有一种更自然的方式来编写addChild()
语句,那就是从父母添加子,而不是另一种方式,因为这是语法规定的顺序。所以,尝试使用自然方式,当失败时,另一种方式仍然没问题,只是有点尴尬。