We have reduced support for legacy browsers.

What does this mean for me? You will always be able to play your favorite games on Kongregate. However, certain site features may suddenly stop working and leave you with a severely degraded experience.

What should I do? We strongly urge all our users to upgrade to modern browsers for a better experience and improved security.

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

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.

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.

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)`.

> *Originally posted by **[BobJanova](/forums/4/topics/320983?page=1#posts-6758464):***
>
> 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.

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.

> *Originally posted by **[Draco18s](/forums/4/topics/320983#posts-6758483):***
>
> 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)

> *Originally posted by **[BrainStormer](/forums/4/topics/320983?page=1#posts-6757518):***
>
> 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.

> 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.

> *Originally posted by **[Draco18s](/forums/4/topics/320983?page=1#posts-6758483):***
> > *Originally posted by **[BobJanova](/forums/4/topics/320983?page=1#posts-6758464):***
> >
> > 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).

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.

> *Originally posted by **[Draco18s](/forums/4/topics/320983?page=1#posts-6775295):***
> > *Originally posted by **[OctaBech](/forums/4/topics/320983?page=1#posts-6766106):***
> > > *Originally posted by **[Draco18s](/forums/4/topics/320983?page=1#posts-6758483):***
> > > > *Originally posted by **[BobJanova](/forums/4/topics/320983?page=1#posts-6758464):***
> > > >
> > > > 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](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.

> 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.

> *Originally posted by **[BrainStormer](/forums/4/topics/320983#posts-6777721):***
>
> I have a strong opinion, and you’ll never convince me otherwise
well, that’s a stupid stance to have on anything.

> *Originally posted by **[skyboy](/forums/4/topics/320983?page=1#posts-6794614):***
> > *Originally posted by **[BrainStormer](/forums/4/topics/320983#posts-6777721):***
> >
> > 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.