There is one usecase that most Flash developers will come across. Lets say we have a loader.swf in which the main (or base) class is Loader.as. Loader.as loads main.swf, main.swf has as main (or base) class Main.as. Loader.as needs to give a signal to the loaded main.swf and tries to type the instance on the stage as Main. This way, Loader.as will makes sure the file that is loaded is who he expects it to be (namely Main.as). The above situation poses a problem. If Loader.as references Main.as, Main.as will be compiled into loader.swf as well. In most cases this will result in a loader.swf that is of the same size as main.swf. In order to fix this we need to make use of an interface. The Main.as will implement the interface and Loader.as will type Main.as not as Main, but as the interface. This way only the interface will be compiled into the loader and not the implementation (or Main.as). While this solves the problem described earlier it also gives some extra benefits. The loader is suddenly reusable. It no longer depends on a specific implementation of any class. It will accept all classes that implement the interface. I hope this usecase adds anything to the discussion. Greetz Erik On Tue, Aug 26, 2008 at 4:32 AM, ben gomez farrell <[EMAIL PROTECTED]>wrote:
> Yah, maybe the word isn't "contract" but a "contract with loopholes". > Anyway, it does a good job of getting intention across, regardless, across > a broad set of code. But yah, i can see the value in it, and I can see that > its a little extra effort that might not be worth it. I'm still more in the > stage where I try to apply it to things to see if it's useful. I'm not sure > if it's helped so far, but it hasn't hurt. > > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
