On Wed, Aug 27, 2008 at 7:30 AM, Mark Winterhalder <[EMAIL PROTECTED]> wrote:
> Say you write a class that draws a pretty chart. It has a method that
> reads a series of values by repeatedly calling readInt(), which is
> guaranteed by IDataInput, and draws that data. If your method takes a
> ByteArray, it works fine for preloaded or locally stored data. If it
> takes a Socket, it works for a live data stream off the net. But if it
> takes an IDataInput, it can do both, without any additional effort --
> you pass it a /data source/, and decide at runtime where you get it
> from.
Mark wins the clear explanation award. :-D
> You don't have to work in a team to appreciate interfaces.
I agree. Other places that I find them useful are:
- Writing some sort of plugin-based system, where app A wants to talk
to app B; both are compiled in isolation (and possibly by different
people or teams). Agreeing on and writing a simple interface means
that both apps can be compiled against that interface, and it really
doesn't matter about the internals of either app. For example, a
portal site that loads games; the portal might offer an interface to
the loaded games to be able to record their scores. If written to an
interface (rather than compiled against potentially changing more
complex code), games written for portal v1 will work for portal v3 and
beyond. Or maybe even for other people's portals. :-)
- The same applies to an app that's broken into modules; if the main
app contains all the 'real' code and the submodules are written to
talk to interfaces, then the bulk of the code is only compiled (and
loaded) once. (You can achieve the same thing with externs or exclude
lists, but I find it easier with interfaces.)
- As a marker or tag. (This is used a lot in Java). If you want to
mark somehow that a class is 'special' - the typical example would be
if you want to mark a class as being safely serialisable without
additional code - you have it implement an interface with no methods
e.g. public interface ISerializable {}. If your class implements that
interface, then the test 'if (yourObj is ISerializable)' comes out
true, and your code can make decisions based on that. (This is how
things were done before metadata - in AS3, I'd do it with metadata.)
- Where inheritance really doesn't work. For example, what if you want
to offer a common logging facility - say a log() method - to loaded
classes within your application. You could pass them an instance of
your main application, MyApp, which defines the log() method. But what
if you reuse that code in another app, MyApp2? Then you'd either need
to recompile, or find a common base class. Fine, create a common base
class - CommonApp, which defines the log() method, and have MyApp and
MyApp2 both derive from that. But what if those two apps are unrelated
and can't inherit from a common user-defined base class - for example,
one is a WindowedApplication (for use in AIR) and the other is a plain
old Application? They can't share a common base... so what do you pass
to your classes that want a logger and where do you define log()? The
answer is to define a common interface, e.g. IApp that supports log(),
and pass that instead.
That is probably far less clear than Mark's example. :-)
Ian
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
