Question

I have made an interface called IHero i implement in my hero.as3 class.
the hero class is written so it can be inheritted in a movieclip class to handle movement etc etc. But somehow i can’t figure out how to code this with a good practice.

Maybe i am in the wrong direction.

I want to have a movieclip subclass, which will be a hero for instance.

Should i just implement the IHero in the hero class with the following methods, or is this to overkill? – I guess I am looking for an answer upon what should be in an interface and what should not. Here is the interface.

package com.interfaces
{
    public interface IHero
    {
        //movement
        function MoveLeft():void;
        function MoveRight():void;
        function MoveUp():void;
        function MoveDown():void;

        //in battle
        function DoDamage(isCasting:Boolean):void;
        function DoHeal():void;
        function Flee():void;
        function TakeDamage():void;
        function IsAlive():Boolean;
        function CheckDeath():void;
        function Die():void;
    }
}

Answer 1

I think you are on a right track, whether its the right one or the wrong one is always subjective. But if you do want to go down this road, I suggest you read this article by Mick West. Its a few years old, but its still very applicable.

I think you really have two distinct interfaces, but probably more

public interface IMoveable {
    function moveLeft(obj:DisplayObject):void;
    function moveRight(obj:DisplayObject):void;
    function moveUp(obj:DisplayObject):void;
    function moveDown(obj:DisplayObject):void;
    function Flee(obj:DisplayObject);
}

public interface IFightable {
    function doDamage(withWeapon:IEquipableWeapon);
    function takeDamage(fromWeapon:IEquipableWeapon);
    function get isAlive():Boolean;
    function checkDeath():void;
    function Die():void;
    function doHeal();
    function get health():Number;
}

Then….

public class SimpleMover implements IMoveable {
    // The movement implementation

    // for example:

    public funciton moveLeft(obj:DisplayObject) {
        obj.x = obj.x -= 10;
    } 
}

public class SimpleFighter implements IFightable {
    // The fighting implementation

    private var _health:Number = 100;

    function doDamage(withWeapon:IEquipableWeapon) {
        _health -= withWeapon.damage;
    }
}

Then inject those into your subclass MovieClip for your Hero.

public class Hero extends MovieClip {

    private var _mover:IMoveable;
    private var _fighter:IFightable;

    public function Hero(mover:IMoveable, fighter:IFightable) {
        _mover = move;
        _fighter = fighter;
    }

}

Here you are using the Hero class as both Component Manager and Render component, which goes slightly against what West is talking about in the article, but I digress. But the idea is that your Manager (the Hero) becomes more or less an orchestrator, proxying calls back through to which ever component is applicable; calling methods on _mover and fighter to do your actual work.

There are several advantages using an approach like this, and some disadvantages. First, its more complex to set up; it requires you to really like about components and what each logical chunck of code is going to do. But on the other hand, it decouples your implementations from each other, makes it more testable, and reuseable. You can also swap out components at any time (compile-time or run-time for that matter), which gives you some flexability when creating new Entities.

But anyway, its just a suggestion of a slightly different paradigm that you seem to be flirting with. Maybe you’ll get some mileage out of it. But definitely give the article a read, if you haven’t already.

Also look into (like check out the API) for the Unity Engine which has a similar aggregation vs inheritance model where interfaces are key to abstraction.