Re: [Flashcoders] Inheritance and abstract classes
I want it to match examples as: Bathroom HAS-A Baththub. Cat IS-A Feline. Cat IS-NOT-A Simalian, but Cat HAS-A Simalian owner. MovieClip IS-A Sprite, but a Sprite can HAVE-A MovieClip child. Loader HAS-A Sprite accessible by the content property. Bitmap HAS-AN associated BitmapData. Socket IS-AN IDataOutput, but Socket IS also AN EventDispatcher. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Inheritance and abstract classes
IS-A = Inheritance HAS-A = Composition Inheritance: Rose extends Flower Composition: MyGarden.rose = new Rose() hth, Cedric I want it to match examples as: Bathroom HAS-A Baththub. Cat IS-A Feline. Cat IS-NOT-A Simalian, but Cat HAS-A Simalian owner. MovieClip IS-A Sprite, but a Sprite can HAVE-A MovieClip child. Loader HAS-A Sprite accessible by the content property. Bitmap HAS-AN associated BitmapData. Socket IS-AN IDataOutput, but Socket IS also AN EventDispatcher. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Inheritance and abstract classes
Ooops, my bad - I have the picture now :) On 23/09/2010 20:51, Henrik Andersson wrote: Glen Pike skriver: has a (interfaces) than is a (subclass), That's wrong. HAS-A is not used for interfaces, it is used for reference properties and other forms of containment. Both interfaces and classes use the IS-A relation. You don't say Picture HAS-A IDrawable, you say Picture IS-A IDrawable. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] Inheritance and abstract classes
You can have an engine that checks collisions and accepts IHitable objects;
another engine would be in charge of moving the objects around and so it
takes IMoveable object
Juan, excellent, excellent post. So in a case like that, sounds like you would
often just typecast method arguments as an interface and not a concrete class,
right?
i.e. instead of:
public function moveIt(moveObject:MoveObject):void{}
do this:
public function moveIt(moveObject:IMoveable):void{}
Jason Merrill
Instructional Technology Architect
Bank of America Global Learning
tweets @ jmerrill_2001
Join the Bank of America Flash Platform Community and visit our Instructional
Technology Design Blog
(Note: these resources are only available to Bank of America associates).
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Juan Pablo
Califano
Sent: Friday, September 24, 2010 1:15 AM
To: Flash Coders List
Subject: Re: [Flashcoders] Inheritance and abstract classes
Despite what the naming conventions are, since the only thing, IMHO, that
interfaces are useful for, is determining if the object being passed to a
method complies and has methods/properties that can be used, without having to
write code to check if the object being passed actually has all the desired
methods/properties.
You can already do that with a class. As long the language is static typed (or
is dynamically typed but types contranis are enforced at compile-time, as in AS
2.0 and in some cases AS 3.0), the compiler checks that without the need of an
interface.
I'd say that, conceptually, an interface is every method and property (and
event, arguably) that a type exposes. So, you know x, y, height, widht, etc,
are part of DisplayObject's interface (even though DisplayObject is a class;
one you cannot instantiate or derive from without crashing at runtime, though;
but that's more a hack hardcoded in the player for the lack of support of
abstract classes in the language; and if you ask me, DisplayObject should have
been an interface or there should be an IDisplayObject interface, but I
digress).
Now, knowing an object has certain capabilities is very useful, especially when
writting libraries, frameworks and that sort of code. Your code could declare
that it accepts objects that comply with certain interface (and here I don't
mean necessarily the interface keyword / construct, but rather what I said in
the previous paragraph). This is what you pointed out. But the difference is
that you can have an object implement an interface without coupling it with
some concrete class. So it's more flexible and it's possible for some object to
implement more than one interface (and possibly unrelated interfaces).
In a game, for instance, you can have entities (or whatever you like to call
it). Following you IMoveable example, you could have other interfaces such as
IShooter, IHitable, etc. You can have an engine that checks collisions and
accepts IHitable objects; another engine would be in charge of moving the
objects around and so it takes IMoveable object; another could be in charge of
common tasks that need to be performed on shooters, so I'd act on IShooter's;
and so on.
Now, the advantage of using interfaces is that you can combine these sets of
functionalities (as declared by the interfaces) in one object indepently,
without having to force inheritance relations that might not make sense and
could add nasty side-effects. I.e. an object could be hitable but not moveable,
a shooter could be either moveable / not moveable, etc. So you could have a
turret (IHitable, IShooter, but not IMoveable), and wall / obstacle (IHitable
but not IMovable nor IShooter), and enemy ship (IHitable, IShooter and
IMoveable), a bullet (IMoveable and IHitable but not IShooter since it doesn't
shoot by itself). Without interfaces and only realying on inheritance this
could turn into a mess rather quickly.
This is important in languages such as Actionscript (which took the idea from
Java), because multiple inheritance is not allowed. In other languages such as
C++, you can have a class inherit from (and hence being-a) any number of
classes so the interface construct / syntax is not necessary (although multiple
inheritance has other drawbacks and is more complex, and that's why it was left
out of Java and other languages followed it this idea).
That said, you don't need to have interfaces or even abstract classes for
everything, in my opinion. This adds flexibility and some space for future
expansion but it comes at the cost of making things more complex. If you're
writing a library and want to allow different clients to use it, having your
methods accept interfaces instead of concrete / abstract classes is a good
idea. You can even provide some default / minimal implementation but leave it
open to your clients to implement
Re: [Flashcoders] Inheritance and abstract classes
Jason, I'm glad you liked it.
Yes, that's precisely the idea. Passing (or actually accepting) an interface
instead of a concrete class.
Following this principle, you could for example use some third party library
for collision detection instead of writting your own if you find one that
fulfills your requirements. This is a good example of when interfaces make
most sense (3rd party libraries). Suppose the author of this engine typed
the input param as some concrete class. It could be then complicated to
integrate with your game objects, because you'd have a hard requirement of
extending a given class, but your object probably already extends something
else. However, if it's an interface, it could be relativeley simple to
integrate, as long as you implement the methods that the interface declares.
And you are free to model your objects hierarchy as you see fit.
Cheers
Juan Pablo Califano
2010/9/24 Merrill, Jason jason.merr...@bankofamerica.com
You can have an engine that checks collisions and accepts IHitable
objects;
another engine would be in charge of moving the objects around and so it
takes IMoveable object
Juan, excellent, excellent post. So in a case like that, sounds like you
would often just typecast method arguments as an interface and not a
concrete class, right?
i.e. instead of:
public function moveIt(moveObject:MoveObject):void{}
do this:
public function moveIt(moveObject:IMoveable):void{}
Jason Merrill
Instructional Technology Architect
Bank of America Global Learning
tweets @ jmerrill_2001
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(Note: these resources are only available to Bank of America associates).
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com [mailto:
flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Juan Pablo
Califano
Sent: Friday, September 24, 2010 1:15 AM
To: Flash Coders List
Subject: Re: [Flashcoders] Inheritance and abstract classes
Despite what the naming conventions are, since the only thing, IMHO, that
interfaces are useful for, is determining if the object being passed to a
method complies and has methods/properties that can be used, without having
to write code to check if the object being passed actually has all the
desired methods/properties.
You can already do that with a class. As long the language is static typed
(or is dynamically typed but types contranis are enforced at compile-time,
as in AS 2.0 and in some cases AS 3.0), the compiler checks that without the
need of an interface.
I'd say that, conceptually, an interface is every method and property (and
event, arguably) that a type exposes. So, you know x, y, height, widht, etc,
are part of DisplayObject's interface (even though DisplayObject is a class;
one you cannot instantiate or derive from without crashing at runtime,
though; but that's more a hack hardcoded in the player for the lack of
support of abstract classes in the language; and if you ask me,
DisplayObject should have been an interface or there should be an
IDisplayObject interface, but I digress).
Now, knowing an object has certain capabilities is very useful, especially
when writting libraries, frameworks and that sort of code. Your code could
declare that it accepts objects that comply with certain interface (and
here I don't mean necessarily the interface keyword / construct, but rather
what I said in the previous paragraph). This is what you pointed out. But
the difference is that you can have an object implement an interface without
coupling it with some concrete class. So it's more flexible and it's
possible for some object to implement more than one interface (and possibly
unrelated interfaces).
In a game, for instance, you can have entities (or whatever you like to
call it). Following you IMoveable example, you could have other interfaces
such as IShooter, IHitable, etc. You can have an engine that checks
collisions and accepts IHitable objects; another engine would be in charge
of moving the objects around and so it takes IMoveable object; another could
be in charge of common tasks that need to be performed on shooters, so I'd
act on IShooter's; and so on.
Now, the advantage of using interfaces is that you can combine these sets
of functionalities (as declared by the interfaces) in one object indepently,
without having to force inheritance relations that might not make sense and
could add nasty side-effects. I.e. an object could be hitable but not
moveable, a shooter could be either moveable / not moveable, etc. So you
could have a turret (IHitable, IShooter, but not IMoveable), and wall /
obstacle (IHitable but not IMovable nor IShooter), and enemy ship (IHitable,
IShooter and IMoveable), a bullet (IMoveable and IHitable but not IShooter
since it doesn't shoot by itself). Without interfaces and only realying on
inheritance this could turn
RE: [Flashcoders] Inheritance and abstract classes
Cool - thanks for the follow-up. Good discussion.
Jason Merrill
Instructional Technology Architect
Bank of America Global Learning
tweets @ jmerrill_2001
Join the Bank of America Flash Platform Community and visit our Instructional
Technology Design Blog
(Note: these resources are only available to Bank of America associates).
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Juan Pablo
Califano
Sent: Friday, September 24, 2010 3:17 PM
To: Flash Coders List
Subject: Re: [Flashcoders] Inheritance and abstract classes
Jason, I'm glad you liked it.
Yes, that's precisely the idea. Passing (or actually accepting) an interface
instead of a concrete class.
Following this principle, you could for example use some third party library
for collision detection instead of writting your own if you find one that
fulfills your requirements. This is a good example of when interfaces make most
sense (3rd party libraries). Suppose the author of this engine typed the input
param as some concrete class. It could be then complicated to integrate with
your game objects, because you'd have a hard requirement of extending a given
class, but your object probably already extends something else. However, if
it's an interface, it could be relativeley simple to integrate, as long as you
implement the methods that the interface declares.
And you are free to model your objects hierarchy as you see fit.
Cheers
Juan Pablo Califano
2010/9/24 Merrill, Jason jason.merr...@bankofamerica.com
You can have an engine that checks collisions and accepts IHitable
objects;
another engine would be in charge of moving the objects around and
so it
takes IMoveable object
Juan, excellent, excellent post. So in a case like that, sounds like
you would often just typecast method arguments as an interface and not
a concrete class, right?
i.e. instead of:
public function moveIt(moveObject:MoveObject):void{}
do this:
public function moveIt(moveObject:IMoveable):void{}
Jason Merrill
Instructional Technology Architect
Bank of America Global Learning
tweets @ jmerrill_2001
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(Note: these resources are only available to Bank of America associates).
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com [mailto:
flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Juan Pablo
Califano
Sent: Friday, September 24, 2010 1:15 AM
To: Flash Coders List
Subject: Re: [Flashcoders] Inheritance and abstract classes
Despite what the naming conventions are, since the only thing, IMHO,
that interfaces are useful for, is determining if the object being
passed to a method complies and has methods/properties that can be
used, without having to write code to check if the object being passed
actually has all the desired methods/properties.
You can already do that with a class. As long the language is static
typed (or is dynamically typed but types contranis are enforced at
compile-time, as in AS 2.0 and in some cases AS 3.0), the compiler
checks that without the need of an interface.
I'd say that, conceptually, an interface is every method and property
(and event, arguably) that a type exposes. So, you know x, y, height,
widht, etc, are part of DisplayObject's interface (even though
DisplayObject is a class; one you cannot instantiate or derive from
without crashing at runtime, though; but that's more a hack hardcoded
in the player for the lack of support of abstract classes in the
language; and if you ask me, DisplayObject should have been an
interface or there should be an IDisplayObject interface, but I digress).
Now, knowing an object has certain capabilities is very useful,
especially when writting libraries, frameworks and that sort of code.
Your code could declare that it accepts objects that comply with
certain interface (and here I don't mean necessarily the interface
keyword / construct, but rather what I said in the previous
paragraph). This is what you pointed out. But the difference is that
you can have an object implement an interface without coupling it with
some concrete class. So it's more flexible and it's possible for some
object to implement more than one interface (and possibly unrelated
interfaces).
In a game, for instance, you can have entities (or whatever you like
to call it). Following you IMoveable example, you could have other
interfaces such as IShooter, IHitable, etc. You can have an engine
that checks collisions and accepts IHitable objects; another engine
would be in charge of moving the objects around and so it takes
IMoveable object; another could be in charge of common tasks that need
to be performed on shooters, so I'd act on IShooter's; and so on.
Now, the advantage
Re: [Flashcoders] Inheritance and abstract classes
Well, although it is good to know the accepted lingo, and although I
must say Juan's post was an enjoyable read, I do have to say that it
supports my point, and Jason's post illustrated exactly what I was saying.
(...continuing my IMove example, which was most definitely not as clear,
but is what you were describing with your collision detection example)
I believe an interfaces only real usefulness is in the ability to make
sure it conforms without having to a bunch of checks. Because you could
have thousands of different animals, like cat, dog, human, etc., but
unless using * as the type
e.g.
makeItJump (obj:*){/*code to test if it can jump goes here, and then
code to make it jump*/}
makeItRun(obj:*){/*code to test if it can run goes here, and then code
to make it run*/}
and then checking that the object was in a list of objects allowed to
use makeItJump, or testing if the passed object had the required
methods, it can only type check against one type at a time; yet, an
interface can allow all animals that have the IMoveable interface cat,
dog, human, rodent, etc.. without having all that code
e.g.
makeItJump(obj:IMove){/*code to make it jump goes here*/}
makeItRun(obj:IMove){/*code to make it run goes here*/}
which, is obviously better; yet, by just looking at it, it seems that it
should be has-a, because you are testing if it has the capability to do
something, or has-a given interface. Therefore, considering you are
essentially asking if it's capable, I think the logic for the accepted
lingo is screwy.
Unless you are just trying to get across that it is-an object that is
movable, I still think that the usage of is-a has-a as descriptions is
non-sense.
I-am Anthony
Anthony is-a Human
Anthony has-a voice because he implements the voicebox interface
But Anthony just has to be difficult and different, so please excuse him.
On 9/23/2010 10:37 PM, Anthony Pace wrote:
On 9/23/2010 3:51 PM, Henrik Andersson wrote:
you say Picture IS-A IDrawable.
Despite what the naming conventions are, since the only thing, IMHO,
that interfaces are useful for, is determining if the object being
passed to a method complies and has methods/properties that can be
used, without having to write code to check if the object being passed
actually has all the desired methods/properties.
e.g. According to my understanding:
human, cat, dog are different objects, but they all have an
IMoveAround interface
So I know If I pass one of the objects to a method that it can use the
blueprints defined by the interface without something breaking, and
have each walk,crawl, Jump, etc... in their own way.
so shouldn't it be has-a? or it-has? or they-have? or is-able?
Maybe I am not experienced enough with solid OOP, but that's the way I
am understanding things right now.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Inheritance and abstract classes
Hi, If you type as a superclass you are generally programming to an interface, so you can just as easily type to an interface. Using interfaces is generally more flexible - it's easier to work with has a (interfaces) than is a (subclass), but sometimes you need a default implementation for your interface, which is why there are a number of abstract classes in AS3 that implement the interface - you need some generic behaviour, it can go in a super-class, but concrete classes are often difficult to deal with when you want to swap between interfaces. E.g. unlike C++ with multiple inheritance, you can only extend a single class, but you can implement as many interfaces as you want. People will generally tell you to work with interfaces, but there are times - and you will find out somewhere along the line, where only a superclass will do. For a simple example of this, look at what we do with Sprites and MovieClips when we extend them. Hope this helps. If you have not looked at Head First Design Patterns, or a similar book about patterns, then they will give you a more in-depth grounding than I can. Glen On 23/09/2010 17:42, Doug Lambert wrote: Inheritance and abstract classes The examples I've seen are set up this way: Super class (abstract class) contains all methods Subclass overrides methods in super class Class instances are typed as super class and instantiated as subclass. I'm wondering why the examples show instances typed as a super class and instantiated as a subclass. This makes it necessary for all methods to exist in the super(abstract) class and overridden in the subclass. Is this on purpose so the abstract class acts as an interface? Wouldn't it be more flexible to type and instantiate as the subclass so methods can be added to the subclass that don't exist in the super(abstract) class? I like the idea of abstract classes. I'm just trying to figure out the best way to use them. Thanks. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Inheritance and abstract classes
Glen Pike skriver: has a (interfaces) than is a (subclass), That's wrong. HAS-A is not used for interfaces, it is used for reference properties and other forms of containment. Both interfaces and classes use the IS-A relation. You don't say Picture HAS-A IDrawable, you say Picture IS-A IDrawable. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Inheritance and abstract classes
On 9/23/2010 3:51 PM, Henrik Andersson wrote: you say Picture IS-A IDrawable. Despite what the naming conventions are, since the only thing, IMHO, that interfaces are useful for, is determining if the object being passed to a method complies and has methods/properties that can be used, without having to write code to check if the object being passed actually has all the desired methods/properties. e.g. According to my understanding: human, cat, dog are different objects, but they all have an IMoveAround interface So I know If I pass one of the objects to a method that it can use the blueprints defined by the interface without something breaking, and have each walk,crawl, Jump, etc... in their own way. so shouldn't it be has-a? or it-has? or they-have? or is-able? Maybe I am not experienced enough with solid OOP, but that's the way I am understanding things right now. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Inheritance and abstract classes
Despite what the naming conventions are, since the only thing, IMHO, that interfaces are useful for, is determining if the object being passed to a method complies and has methods/properties that can be used, without having to write code to check if the object being passed actually has all the desired methods/properties. You can already do that with a class. As long the language is static typed (or is dynamically typed but types contranis are enforced at compile-time, as in AS 2.0 and in some cases AS 3.0), the compiler checks that without the need of an interface. I'd say that, conceptually, an interface is every method and property (and event, arguably) that a type exposes. So, you know x, y, height, widht, etc, are part of DisplayObject's interface (even though DisplayObject is a class; one you cannot instantiate or derive from without crashing at runtime, though; but that's more a hack hardcoded in the player for the lack of support of abstract classes in the language; and if you ask me, DisplayObject should have been an interface or there should be an IDisplayObject interface, but I digress). Now, knowing an object has certain capabilities is very useful, especially when writting libraries, frameworks and that sort of code. Your code could declare that it accepts objects that comply with certain interface (and here I don't mean necessarily the interface keyword / construct, but rather what I said in the previous paragraph). This is what you pointed out. But the difference is that you can have an object implement an interface without coupling it with some concrete class. So it's more flexible and it's possible for some object to implement more than one interface (and possibly unrelated interfaces). In a game, for instance, you can have entities (or whatever you like to call it). Following you IMoveable example, you could have other interfaces such as IShooter, IHitable, etc. You can have an engine that checks collisions and accepts IHitable objects; another engine would be in charge of moving the objects around and so it takes IMoveable object; another could be in charge of common tasks that need to be performed on shooters, so I'd act on IShooter's; and so on. Now, the advantage of using interfaces is that you can combine these sets of functionalities (as declared by the interfaces) in one object indepently, without having to force inheritance relations that might not make sense and could add nasty side-effects. I.e. an object could be hitable but not moveable, a shooter could be either moveable / not moveable, etc. So you could have a turret (IHitable, IShooter, but not IMoveable), and wall / obstacle (IHitable but not IMovable nor IShooter), and enemy ship (IHitable, IShooter and IMoveable), a bullet (IMoveable and IHitable but not IShooter since it doesn't shoot by itself). Without interfaces and only realying on inheritance this could turn into a mess rather quickly. This is important in languages such as Actionscript (which took the idea from Java), because multiple inheritance is not allowed. In other languages such as C++, you can have a class inherit from (and hence being-a) any number of classes so the interface construct / syntax is not necessary (although multiple inheritance has other drawbacks and is more complex, and that's why it was left out of Java and other languages followed it this idea). That said, you don't need to have interfaces or even abstract classes for everything, in my opinion. This adds flexibility and some space for future expansion but it comes at the cost of making things more complex. If you're writing a library and want to allow different clients to use it, having your methods accept interfaces instead of concrete / abstract classes is a good idea. You can even provide some default / minimal implementation but leave it open to your clients to implement their own and still be able to use your library, without having to extend some class (which is not always possible / practical). In lots of application code, though, I think you don't really need this extra flexibility and many times it adds more work for little benefit. Cheers Juan Pablo Califano 2010/9/23 Anthony Pace anthony.p...@utoronto.ca On 9/23/2010 3:51 PM, Henrik Andersson wrote: you say Picture IS-A IDrawable. Despite what the naming conventions are, since the only thing, IMHO, that interfaces are useful for, is determining if the object being passed to a method complies and has methods/properties that can be used, without having to write code to check if the object being passed actually has all the desired methods/properties. e.g. According to my understanding: human, cat, dog are different objects, but they all have an IMoveAround interface So I know If I pass one of the objects to a method that it can use the blueprints defined by the interface without something breaking, and have each walk,crawl, Jump, etc... in their own way. so shouldn't it be has-a? or it-has? or
