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