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

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