Is it possible to "inherit" an interface from a type?

19 posts

Flag Post

Hi.

var image:IGenericImage = Factory.produceGenericImage();
image.load(IMAGES_PATH + model.image + ".jpg");
addChild(image as Sprite);

IGenericImage is an interface.
Here I cannot just addChild(image) because it’s type is not known (except it’s an Object), but in fact it is a Sprite. So I have to cast it as a Sprite everywhere. Also I’ll have to define a heap of other methods (like get x, set x, get y, set y, eight methods for all the rotations etc) in the interface.

Isn’t there a way to like inherit an interface from say the Sprite type?

Thank you.

 
Flag Post

Why don’t you extend Sprite and implement an interface in your class?

public class GenericImage extends Sprite implement IGenericImage {...}

 
Flag Post

It is extended. But in the construction

var image:IGenericImage = Factory.produceGenericImage();

the ‘image’ variable is of IGenericImage (interface) type, not just GenericImage. So I cannot addChild the ‘image’ because the interface IGenericImage is not a Sprite nor can it extend Sprite unfortunately.

 
Flag Post
Factory

So. Is that a hammer factory factory, or just a hammer factory?

Why not use a god damn hammer?

 
Flag Post

I’m not sure the factory is the issue here, though I agree.

The answer is no. The workaround is to specify function get displayObject() : DisplayObject on the interface, and call addChild(image.displayObject).

 
Flag Post
Originally posted by BobJanova:

I’m not sure the factory is the issue here, though I agree.

True, it isn’t, but the whole…factory design thing boggles my mind.

 
Flag Post

Yeah, I am not a fan of the factory pattern either. Most of the time you can just use an interface and object constructors. It’s particularly prevalent in Java where I’m working at the minute, but I’ve seen it in AS sometimes too.

 
Flag Post

Originally posted by Draco18s:

True, it isn’t, but the whole…factory design thing boggles my mind.

i’m pretty sure it came about when people began using complex objects in pools; good intentions gone corporate: they needed a way to reset all the variables and return the clean object, an instance method would work but looks ugly so static methods were used and it just got corrupted and simplified and compartmentalized from there until a CEO would look at it and say “so, can you make it bigger?” (basically, it’s an ongoing process)

 
Flag Post
Originally posted by BrainStormer:

It is extended. But in the construction

var image:IGenericImage = Factory.produceGenericImage();

the ‘image’ variable is of IGenericImage (interface) type, not just GenericImage. So I cannot addChild the ‘image’ because the interface IGenericImage is not a Sprite nor can it extend Sprite unfortunately.

Well, you can then do one single typecast like var sp:Sprite=image as Sprite; if (!sp) panic(); and refer to Sprite’s method set via “sp”, and to IGenericImage’s method set via “image”. You can also do a typecast to your extended class instead of Sprite, should also work.

 
Flag Post

i’m pretty sure it came about when people began using complex objects in pools; good intentions gone corporate

The reason here is much simpler. It’s not even a Factory Pattern actually, just a convenient name for the class which requests and receives broadly typed objects and then returns them. The whole thing is to eliminate any class dependencies between the object recepient (where I put that image) and the object’s class (the GenericImage itself) so I don’t have to wait about a minute for the IDE to rebuild the project each time after I make a tiny edit and press CTRL+S (which is meant to be done often). If nothing depends directly on the edited class then only that class gets rebuilt. Also cuts time during incremental compilation. It has nothing to do with patterns or coding habits, just a workaround for a silly problem.

Thanks, everyone!

PS: Sorry for my English.

 
Flag Post

Ah, well in that case, use a decent IDE :-)

 
Flag Post

I don’t know any more decent IDE than the latest FDT. Flash builder doesn’t do a bunch of critical things, so does not FlashDevelop.

 
Flag Post
Originally posted by Draco18s:
Originally posted by BobJanova:

I’m not sure the factory is the issue here, though I agree.

True, it isn’t, but the whole…factory design thing boggles my mind.

It’s meant for flexible code, where the same system branches out to multiple distributions with different demands, which calls for different strategies.

The main code-base doesn’t contain creation of new objects (new Object), but instead calls a create function from the Factory (Factory.createObject()). This way the code-base can be compiled for different distributions by simply being feed with different factories which create the right strategies when called.

If the code-base only is meant for one game, it doesn’t make much sense to use the Factory pattern other than one got the creation of new objects neatly isolated into one class (I agree, in this case it just make things more complicated).

 
Flag Post
Originally posted by OctaBech:
Originally posted by Draco18s:
Originally posted by BobJanova:

I’m not sure the factory is the issue here, though I agree.

True, it isn’t, but the whole…factory design thing boggles my mind.

It’s meant for flexible code, where the same system branches out to multiple distributions with different demands, which calls for different strategies.

Read this:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431

 
Flag Post

I have a strong opinion, and you’ll never convince me otherwise, that only the programmer that does the task decides which tools to use and which way to use them for that task. If you know how to use a factory and you feel comfortable and convenient with it then use it as long as it makes the job done the better way. Yes, if it is a spice rack then maybe you need just a hammer, but if your task is to build a Boeing and you are going to do it all with hammers, well then, you’re screwed.

 
Flag Post
Originally posted by Draco18s:
Originally posted by OctaBech:
Originally posted by Draco18s:
Originally posted by BobJanova:

I’m not sure the factory is the issue here, though I agree.

True, it isn’t, but the whole…factory design thing boggles my mind.

It’s meant for flexible code, where the same system branches out to multiple distributions with different demands, which calls for different strategies.

Read this:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431

The problem with the analogy is that he shouldn’t be looking for a hammer-framework in the first place, unless his purpose was to make a factory which produces spice racks. He seems to be of the common misconception that frameworks and collections are the same, which they aren’t. Frameworks are not universal tools, they are highly specialized for their purpose and are in full control of everything but the hotspots used to tailor for special demands within its realm of its purpose. He shouldn’t be looking for a hammer but a rack-framework which then can be customized after his needs. In cases where it’s necessary to combine multiple frameworks they should be kept strongly separated by the facade-pattern.

What he complains about are things he shouldn’t even be touching, the factory pattern is used to make the code flexible and maintainable for the people writing the framework, not the user, for whom the code should remain a black box. The user orders something from the framework and gets it, the framework may not be able to deliver the exact product the user wanted, so the user will have to manually compensate with the decorator pattern.

 
Flag Post

he factory pattern is used to make the code flexible and maintainable for the people writing the framework, not the user

And that is why I hate factories. As a “user” in the context here, I like my frameworks to be easy to work with, and factories prevent that. In fact…

the user will have to manually compensate with the decorator pattern

That is why.

 
Flag Post

Originally posted by BrainStormer:

I have a strong opinion, and you’ll never convince me otherwise

well, that’s a stupid stance to have on anything.

 
Flag Post
Originally posted by skyboy:

Originally posted by BrainStormer:

I have a strong opinion, and you’ll never convince me otherwise

well, that’s a stupid stance to have on anything.

And that is your strong opinion on which I am not going to convince you otherwise. Anyway, I’m sorry, didn’t intend to say anything rude.