>> 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: [email protected]
[mailto:[email protected]] 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 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 <[email protected]>
> 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
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
