Calling addChild() from children? Children add themselves?

Question

With the display list in Actionscript 3.0, I'm often inclined to have children add themselves to their parent because they often already have that reference. That would look like:

_myParent.addChild(this);

or when removing...

this.parent.removeChild(this);

By the wording of the addChild() syntax, this way seems backwards -- the name suggests the parent should be the only one calling that function.

• Does anyone else do this?
• Or does this seem backwards and confusing?
• Perhaps I'm getting myself into situations I shouldn't be in?

It seems like a violation of responsibilities because the parent should be the only one calling its own method and in charge of its own display list.

Answer 1

Though it is not a good practice, this.parent.removeChild(this); is sometimes convenient (depending on your design) - and I remember doing it in the early days of AS coding... then i was advised that its not a good way of doing it and i dnt use it anymore.

Regarding _myParent.addChild(this); -- I don't usually pass the parent object to the constructor/methods of child... I think this practice has its roots in AS2. And yeah, it looks strange/confusing since its not the AS3 way.

Answer 2

It seems bad to me as the state of the parent is its children. So by having reference to child you can change parents state and it breaks the encapsulation.

Let`s think of a simple case when you need to implement drag and drop. It can be done in this way:

1. Tell child to remove his him from his parent. Then tell child to add him to a new parent. And parents are not even know about that :-).

2. Tell parent - I need your child. He will remove that child. Then tell to other parent: from now on this child is yours.

   The second way seems more reasonable to me, because if you need to reject some children (parent cant 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), youll be have to call all this from your child class. And this will require show all your parents implementation for that. Sure it can be done via generic interface of parent, but I think its much easier to delegate this responsibility to parent and provide child. Every parent will know what he should do to add this child.

Answer 3

_myParent.addChild(this);

Let's break this down...

• _myParent
  This is a reference to another object, which happens to be the object's parent on the display list. There are many reasons for an object to have a reference to its parent. They are closely related in structure, so likely have reasons to communicate with each other. So, having a reference to the display list parent isn't an issue.

• addChild()
  Calling one of the parent's public methods isn't an issue. That's what methods are for. If this were a property of the parent, it would be invasive. Calling this method won't directly alter the parent's state. The parent will carry out this function at its own discretion.

• this
  The fact that the argument in this case happens to be self-referential is a coincidence. If the argument were something trivial such as new Shape(), it would seem less awkward. But, since an object is essentially "adding itself", it seems something like a person lifting himself up by his/her bootstraps. But, this isn't real life; it's computer programming, and it makes sense when read by its syntax.

Actionscript needed to name the function something. The other alternative for getting a child onto the display list could have been addToParent(), which would still have the same awkward effect when trying to add a child from the parent -- _myChild.addToParent(this).

So, while there are no objects being violated in this awkward predicament, there is a more natural way of writing addChild() statements, and that's to add children from parents, instead of the other way around because that's the order laid down by the syntax. So, try to use the natural way, and when that fails, the other way is still okay, just a little awkward.

Answer 4

You'll want to be cautious whenever a child refers to its parent. While it doesn't break any rules associated with Object-Orientation, it does start to make your Composite structure more difficult to maintain and understand.

The Display List in ActionScript 3.0 is designed to use method calls when interacting with children, and events (sometimes bubbling) whenever a child does something that may be interesting to a parent.

This direction helps us keep children ignorant of their position in the hierarchy, and design them more like general purpose (reusable) components. In general, an ActionScript Display List moves from more to less specific as it moves from parent to child. For example, a CreditCardForm might contain a TextInput control.