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