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