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