Am I making garbage?

innerUFOmaker wrote: Hi, In certain frames of a MC (Sandal)  which I add it to another MC (gamelevel), I  run a hitTestObject between it (Sandal) and some other MCs (they are in bArray). Here in the main class I make the sandal: public function hitBySandal () {             var sandalH:Sprite = new Sprite();             var sandal:Sandal = new Sandal();             sandal.scaleX = .5;             sandal.scaleY = sandal.scaleX;             sandalH.x = mouseX - sandalH.width;             sandalH.y = mouseY - sandalH.height;             sandalH.addChild (sandal);             gamelevel.addChildAt (sandalH, bArray.length + 1);         } and here in some sandal's frames I coded: var mc:MovieClip = MovieClip(this.root);   //this.root is my mainclass addEventListener (Event.ENTER_FRAME, checkHit); function checkHit (event:Event) {     for (var i:int = 0; i < mc.bArray.length - 1; i++) {         if (this.hitTestObject(mc.bArray)) {             mc.kill (mc.bArray);         }     } } I add and remove this eventListener in some other frames where I need to hitTestObject. 1. I need to know if var mc:MovieClip = MovieClip(this.root) is just copying my main class that is a huge scene, and if yes, does it (the memory) completely vanish after removing the sandal? 2. Can I NOT make the mc above and instead work directly with this.root? (it knows this.root BUT not its variables as bArray) For removing sandal and its holder I coded in its last frame: stop (); removeEventListener(Event.ENTER_FRAME, checkHit) this.parent.parent.removeChild (parent); So am I doing things right or just making garbage?

I will take a much stronger position than kglad. If you want to be following good Object Oriented practices, then, yes, you are making garbage.

Here are some rules of Object-Oriented Programming that you are violating:

1. Single Responsibility Principle: Children should only be responsible for themselves. As soon as they are responsible for their parents, they can't be used within parents that are built a different way. Also, the parents get very dependent on these specific children and it becomes really hard to make changes.
2. Liskov Substitution: If you must know about the parent, you should be referring to it as a type of object that declares the properties and methods you'll be using as part of its Type definition.  This allows you to substitute another object of the same type that doesn't happen to be the parent at need (aka loose coupling).
3. Dependency Inversion Principle: Again, if you're going to have a reference to a parent, it should be passed in rather than the child reaching out and grabbing it.

For more on these and other principles you should be aware of, see SOLID. You may also want to look at GRASP, because you're violating Indirection, High Cohesion, Information Expert, and Low Coupling (at least).

Here are some ways to fix this:

Instead of having the child perform the "hit by sandal" action, it should instead simply dispatch a custom event when it detects that this has happened. This can be either on the Display List on an EventDispatcher that is shared by key components of the system (aka an event bus). The parent (or something higher up the chain that properly has the responsibility to act on this event) can then take whatever actions are needed, including adding children to the gameLevel if that's needed. It's possible, though, that you're better off adding a "hit" state to whatever gets hit by the sandal and simply calling the hit() method on those instead.

As Kglad says, you're very likely causing memory leaks by listening to ENTER_FRAME to something that can get removed from the display list if you're not listening to REMOVED_FROM_STAGE and cleaning it up there. Listening to this event causes a direct reference from the stage to whatever function you're adding (and hence the object where that function is declared).

Information Expert says that since your root already knows about your Sandal instance, its own bArray, and its own kill() method, it is a much better candidate to be also carrying out the hit test, so you might want to completely remove any responsibility for knowing if Sandal has hit anything from Sandal and move it closer to Main. Then Sandal becomes a pure, "dumb" Display Class and it is then infinitely portable. You may want to consider adding a Controller in there somewhere to translate back and forth between your Model/Data layer and the View.