CODEWITHSUNDEEP
actionscript-3oop
Will Johnson
Will Johnson

Reputation: 225

OOP Proper use of interfaces in AS3

I'm designing a framework and in the process I have come across an interesting but most likely basic problem. I have a base class called CoreEngine and two other classes that extend it: CoreEngine1 and CoreEngine2. I created an interface that each of these classes would implement to increase the flexibility of my project. However, I have a problem... The definition of my methods in the interface do not match the definition in each inherited class! Each class must implement the following method:

function get avatar():AvatarBase;

The problem is that CoreEngine1 and CoreEngine2 expect a different type of avatar:

CoreEngine1

function get avatar():AvatarScaling

CoreEngine2

function get avatar():AvatarPlatform

As you can see, the return type for avatar in CoreEngine1 and CoreEngine2 do NOT match the type as specified in the interface. I was hoping that since both AvatarScaling and AvatarPlatform inherit AvatarBase that I wouldn't have a problem compiling. However, this is not the case. According to Adobe's documentation, the types MUST match the interface. I am trying to follow one of the core concepts of object oriented programming to extend the flexibility of my framework: "Program to an interface rather than an implementation". The first thing that comes to my mind is that the return type of the accessor method should be of an interface type (Maybe I just answered my own question).

I'm certain this is a common problem others have run into before. Architecturally, what do you think is the best way to solve this problem? Thanks in advance!

Regards,

Will

Upvotes: 2

Views: 1927

Answers (3)

harbinja
harbinja

Reputation: 958

I think you answered your own question... the return type would still be AvatarBase, you need to follow the signature that you specified in the interface... but you can technically return ANY descendent of AvatarBase in that function. So doing something like

return new AvatarScaling();

in CoreEngine1 would be perfectly acceptable.

Of course in your calling function you will get back an AvatarBase instance, and you will have to know what this is in order to cast to a specific subclass.

CoreEngine1 ce1 = new CoreEngine1();
AvatarScaling avatar = ce1.avatar() as AvatarScaling;

Upvotes: 0

recursivity
recursivity

Reputation: 144

Like HotN and Dinko mentioned, it would be best to allow get avatar() to return AvatarBase allways and then cast the returned object as the concrete subclass.

Using Dinko's example:

public /* abstract */ class CoreEngine
{ 
   public /* abstract */ function get avatar():AvatarBase {}
}

public function CoreEngine1 extends CoreEngine
{
   override public function get avatar():AvatarBase { return new AvatarScaling(); }
}

public function CoreEngine2 extends CoreEngine
{
   override public function get avatar():AvatarBase { return new AvatarPlatform(); }
}

public /* abstract */ class AvatarBase {}

public class AvatarScaling extends AvatarBase 
{ 
   public function someAvatarScalingMethod():void {}
}

public class AvatarPlatform extends AvatarBase 
{ 
   public function someAvatarPlatformMethod():void {}
}

To use a method from AvatarScaling, cast the returned object:

var c1:CoreEngine1 = new CoreEngine1();
var avatarScaling:AvatarScaling = AvatarScaling(c1.avatar());
avatarScaling.someAvatarScalingMethod();

hth

Upvotes: 1

Mike Walton
Mike Walton

Reputation: 4386

This is a limitation of how interfaces work and are declared.

If there's inheritance that can happen with the return types, as you've described with AvatarBase and subclasses, then I think the right approach is to make the return type the lowest common denominator and just handle the resulting object on the other end. So, if you're dealing with a CoreEngine1 object, you know you can cast the result from AvatarBase to AvatarScaling. Alternately, if you don't know the object type that you are calling get avatar() on, then you can type check the returned value. The type check would then only be needed if you're looking to call a method that exists on AvatarScaling but not on AvatarBase. I don't think returning an interface type will buy you much in this case because the only things that interface can implement would be things that all forms of Avatar share, which wouldn't be any different than methods in AvatarBase.

Upvotes: 1

Related Questions