Object Oriented Programming in AS3

Question

I'm building a game in as3 that has balls moving and bouncing off the walls. When the user clicks an explosion appears and any ball that hits that explosion explodes too. Any ball that then hits that explosion explodes and so on.

My question is what would be the best class structure for the balls. I have a level system to control levels and such and I've already come up with working ways to code the balls. Here's what I've done.

My first attempt was to create a class for Movement, Bounce, Explosion and finally Orb. These all extended each other in the order I just named them. I got it working but having Bounce extend Movement and Explosion extend Bounce, it just doesn't seem very object oriented because what if I wanted to add a box class that didn't move, but did explode? I would need a separate class for that explosion.

My second attempt was to create Movement, Bounce and Explosion without extending anything. Instead I passed in a reference to the Orb class to each. Then the class stores that reference and does what it needs to do based on events that are dispatched by the Orb such as update, which was broadcast from Orb every enter frame. This would drive the movement and bounce and also the explosion when the time came. This attempt worked as well but it just doesn't seem right.

I've also thought about using Interfaces but because they are more of an outline for classes, I feel like code reuse goes out the window as each class would need its own code for a specific task even if that task is exactly the same.

I feel as if I'm searching for some form of multiple inheritance for classes that as3 does not support.

Can someone explain to me a better way of doing what I'm attempting to do? Am I being to "Object Oriented" by having classed for Movement, Bounce, Explosion and Orb? Are Interfaces the way to go? Any feedback is appreciated!

Answer 1

Gidday,

This reminds me of an example I read not so long ago, and it used almost the same class names for exactly your example! If it helps you find answers, I do rememebr the book was a Friends of Ed publishing and was called "Object Oriented Actionscript" and though it was for AS2, the concept is the same in AS3.

That book aside, in my readings about Design Patterns (un/flame at will, people), it sounds like the Factory pattern could be used to generate different objects generated from a standard object, as you'd override particulars as you need to. The first para on Wikipedia explains that simply, and the diagram is helpful too.

-d

Answer 2

I think you're looking for something like what PushButton Engine does: using Entities and Components. The concept is, you have an Entity class (Orb) which can contain the properties of the orb (maybe position and size) and maybe your rendering code. Then you have Component classes (Movement, Bounce, Explosion) that you attach to your Entity class.

The components should contain only the functionalities that they're supposed to do (i.e. Bounce component should only handle when/where to Bounce and not move the Orb on every frame). They should also have direct access to their owner (Entity) class. For example, they can modify the properties (moving, bouncing) or call explode on it.

You can then make use of the Factory pattern to have a separate Factory class that does the creation of entities and attaching of appropriate components to those entities.

Answer 3

An important rule for any engine or framework is that no matter what kind of inheritance or whatever you actually use, it should be fully optional for an entity to be handled by the engine. So while concrete entities that are handled by the engine may use complex inheritance, to the engine it is fully transparent, because they are abstracted to interfaces.

For example, you define an interface IMovable. The engine can handle this and move around such objects. Then you can provide a default implementation, let's say MovableBase, that can, but need not be reused by other entities through inheritance or composition.

Please also note, that composition is generally considered better and cleaner than inheritance. Overusing inheritance extremely often leads to violation of the Liskov substitution principle which is one of the 5 SOLID principles. You can find a lot of articles about inheritance vs. composition on Google.

Inheritance in common usage actually tends to break many OOP principles and to introduce a lot of dependency. It is often regarded as a fundamental concept in OOP, but you're better off if you conceive it just as one of many ways to achieve code reuse.

So rather than bothering so much with the question, how you will build specific components, first you need to abstract them to be able to apply the dependency inversion principle. This way, you will obtain an architecture with extremely lose coupling. If an entity proves to be unneccessarily complex, or if you find, that you can possibly extract some code for reuse, or that you need to rearrange your inheritance mechanism, no other code is affected.

You may discover, that actually trying to split your entities into multiple layers of inheritance makes only little sense because things become unneccessarily verbous and strangely interwoven. However abstracting different "aspects" or "roles" of your entities, such as IMovable, IBounceable, IExplodable and so on, will proove helpful. Any entity may choose to implement any interface at will and will thus be handled accordingly by the engine.

The most important step in software design is to devise an architecture, wherein different modules are radically split and interact through narrow interfaces. When a module grows big, then apply the same step to it, and refactor it to submodules (you can do so, without having to worry about the rest of the software, simply because the module is well encapsulated). Do not try to split a whole into parts, when it doesn't seem natural. You'll get more code, that is less flexible.

greetz
back2dos