Focusing on the "contract" part always seemed to me a bit misleading about
what interfaces are, from a developer point of view. I mean, I understand
that using an interface will make the compiler force you to "implement" some
method, with some given signature, and I see the value in it, especially
force larger projects, with various developers. Nevertheless, what always
bugged me about this "it will force you to implement this method" approach
is that, well, it does but it depends on how you define "implemeting". One
can arguably claim that this is not a real implementation:
public function doSomeStuff(someArg:int):SomeType {
return null;
}
An still, it's perfectly legal, will compile without a hitch, and will of
course bomb out at runtime if you happent to use that return value for
anything useful.
In think being sure that a method will exist at runtime is a problem that
should concern the people who write a compiler and a runtime, but hardly the
coder who develops using that compiler and targeting that runtime. I mean,
following the "contract" approach, I agreee interfaces are a good language
feature, but I feel like they're often presented as a silver bullet.
On the other hand, interfaces are very useful to make some object to be an
instance of multiple types in a language that doesn't allows multiple
inheritance. And that could be powerful in certain sitautions.
Maybe one example will make the point more clear than some abstract
rambling.
Some time ago, I had to build a kind of "engine" for some simple, 2D games.
Basically, a main character, some enemies with a rather modest IA, some
generic collision detection, the ability to shoot and being shot, and so
on.
I had some managers to handle different aspects like collisions, moving
objects, "chasing" some other objects, etc. The thing was, some kind of
enemy could have the ability to move and get shot, but maybe not shooting.
Some other enemy would just move; another one would just shot but not move;
a wall had to be "hitable", but wouldn't move or shoot, etc, etc. And the
main character could have its own set of "features".
So, the problem was that an object had to be passed to different methods and
I wanted to keep things typed (i.e. not using Object everywhere): the
checkCollision() method would receive two "hitable" objects, for instance,
or the move() method would be called on a "movable" object. My first
approach was using inheritance but it looked ugly and smelled bad. It was
clear that it would be a mess having some enemy class arbitrarily descending
from a Shooter class, which in turn descended from a Movable class, which in
turn inherited from a Hitable class, ad nauseam.
I asked some advice from a co-worker and while discusing it, it ocurred to
us that we could use interfaces to make an object hitable, movable, a
shooter, and so forth. Of course we would lack the specific
"implementation", but the overall result was much more clean, flexible and
mantainable than forcing some weird inheritance relationship. Perhaps having
"real" multiple would have saved some duplicated code, since much of the
code to move some objects was identical and we weren't extending base
classes but implementing interfaces in each movable object. But reading
about it, I found that some more knowleadgeble people than me argue that
having "real" multiple inheritance would add not only a perhaps useful
feature, but a whole new set of problems, so interfaces are a way to keeping
things simpler. So probably not having it is not a bad desing decision -- I
also tend to favour shallower hierarchies whenever possible, so keeping
things as simple as you can is an approach that easily fits my mindset.
So, hopefuly, this could be a modest example of how using interfaces relate
to having an object share a number of different types -- which, admitedly,
is not necessarily and technically the same thing as multiple inheritance,
but I think is conceptually close.
Cheers
Juan Pablo Califano
2008/8/25, Merrill, Jason <[EMAIL PROTECTED]>:
Interfaces have nothing to do with inheritance (at least not directly)
as I understand them. Interfaces are special classes that simply define
what other classes must define. A class that implements an interface
has to define the methods and properties defined in an interface. An
interface is not used directly, it's, like Ben mentioned, a "contractual
agreement" that a class will contain certain things. It's useful in a
team coding environment. Interfaces traditionally start with a capital
letter "I" as in IUserView.as.
Jason Merrill
Bank of America
Enterprise Technology & Global Risk L&LD
Instructional Technology & Media
Join the Bank of America Flash Platform Developer Community
Are you a Bank of America associate interested in innovative learning
ideas and technologies?
Check out our internal Innovative Learning Blog & subscribe.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Sampson
Sent: Monday, August 25, 2008 7:01 PM
To: Flash Coders List
Subject: Re: [Flashcoders] A Question that I've been asking for years!!
I'm certainly no expert but as I understand it, an interface is a class
that
is only good for inheriting, never instantiating.
For example - if you were going to write two classes - Baseball and
Softball, you would want a parent class Ball. However, you won't ever
instantiate a Ball, you'll always use one of the subclasses.
Furthermore,
Baseball and Softball both have similar properties (pitch,
circumference,
weight, etc) but those functions are implemented differently between the
two. So instead of making a Ball class and overriding all the methods
both
times, you would make an Interface that they both implement. You haven't
written any code in the interface, just defined that all Ball objects
will
have a pitch method, and a circumference and weight, and the
implementation
is up to them.
So that's all well and good but the real power is that you can use Ball
as a
data type later to refer to either type: myBall:Ball = new Softball().
I hope that helps -
On Mon, Aug 25, 2008 at 3:39 PM, Omar Fouad <[EMAIL PROTECTED]>
wrote:
This could seem weird...
But what the hell is an interface!!!???????? I've read lots of books
and
posts without getting the answer. I bought "Essential AS3" to read
about
interfaces and he says that helps for multi inheritance. In other
places I
read that it is a "deal" to ensure that a class has some methods and
so on.
But what is the real benefit that I can come out with using
interfaces????
Maybe that is stupidity or I am not smart enough to get the concept
but
believe me... its is been two years now!!
Please Help!!!
--
Omar M. Fouad - Digital Emotions
http://www.omarfouad.net
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.
_______________________________________________
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
