|
Hmmm.... Thanks for your confidence... The pressure is on now... 8-) I wasn't sure about what was clearest for a description, you might want to swap the order of PART 1 and PART 2. Or, you might just want to hit delete now and continue with your day. **INTRO An 'interface' is basically a way to specify something very similar to a generic or abstract class. Its effectively a contract that any class that implements it must honor. And, an object of a class that implements a particular interface, actually becomes an object of that type (very much like extending a class). ** PART 1 By implementing an interface, in general, you are inheriting the contract and type of the interface but not any of the data or code (you inherit behavior because of the contract). Lets try an example. interface ZebraI abstract class ZebraA class z1 implements ZebraI class z2 implements ZebraA As shown below, these two things (ZebraI and ZebraA) are 'almost' the same. The classes that inherit from them are similar in that both of them are a proper subtype of the Zebra*. I.e. z1 IS A zebraI, and z1 IS A zebraC. public interface ZebraI { public void black(); public void white(); } abstract class ZebraC { public abstract void black(); public abstract void white(); } // Get zebra interface contract public class z1 implements ZebraI { public void black() { // implementation } public void white() { // implementation } } // Get both zebraClass implementation AND its contract public class z2 extends ZebraC { public void black() { // implementation } public void white() { // implementation } } Note however for an abstract class, we can provide part of the implementation and the data that defines a zebra if we want to, and allow the class that extends it to inherit it TOO. You cannot provide implementation or data for an interface. ** PART 2 In general, the thought is that inheritence can lead you down the path of the dark side (Ok, I'm a star wars fan), Java architects in their wisdom said... "Though shalt only inherit once"... So. We have the pretty typical invention of 'interface'. Its a mechanism to strongly type a class using a 'base-class-like' thing. But, you get the implementation (code, data) from somewhere else. Some of the nastiness about multiple inheritence: - base class constructors & destructors, their relationships to each other - layout of fields - both base classes implementing methods of the same name and signature - same things for fields of the same name and type in base classes For example: class A { public A(); public void foo(); public int i; } class B { public B(); public void foo(); public int i; } class C extends A, B { // How do the 'i' fields appear in memory? } // What happens here? C x = new C(); //<-- which Ctors run in which order? x.foo(); //<-- which foo() gets called? x.i = 5; //<-- which 'i' is used? It just adds all sorts of nasty, yucky, gork that you've constantly got to think about, and you simply DON'T want to think about everytime someone does multiple inheritence. So... You can't do it. 8-) Instead, you use an interface and 'implements'. You pull the implementation and data for each class from single inheritence OR containment. Its easy to understand. The problems above are avoided, but MUCH MORE IMPORTANTLY, we avoid placing the complexities of remembering and understanding the SOLUTION to the problems on the programmers. Again, A very simple avoidence of multiple inheritence plus the 'interface' and 'implements' concepts make a vastly more simple language. "The stuff we call "software" is not like anything that human society is used to thinking about. Software is something like a machine, and something like mathematics, and something like language, and something like thought, and art, and information... but software is not in fact any of those other things." Bruce Sterling - The Hacker Crackdown Fred A. Kulack - AS/400e Java and Java DB2 access, Jdbc, JTA, etc... IBM in Rochester, MN (Phone: 507.253.5982 T/L 553-5982) mailto:kulack@us.ibm.com Personal: mailto:kulack@bresnanlink.net AOL Instant Messenger: Home:FKulack Work:FKulackWrk "Bartell, Aaron L. (TC)" <ALBartell@taylorcorp.com>@midrange.com on 03/19/2001 05:26:22 PM Please respond to JAVA400-L@midrange.com Sent by: owner-java400-l@midrange.com To: "'JAVA400-L@midrange.com'" <JAVA400-L@midrange.com> cc: Subject: RE: HTML to XML, vice versa Fred, I have been reading about the 'interface' keyword but don't quite understand it. Since I like how you explain things I was wondering if you would do so for the interface keyword. Aaron Bartell -----Original Message----- From: Fred Kulack [mailto:kulack@us.ibm.com] Sent: Friday, March 16, 2001 5:03 PM To: JAVA400-L@midrange.com Subject: RE: HTML to XML, vice versa Ah... You are about to see the light. That method's code is hard to think about because its only a method definition, NOT any code. Yank all the stuff you had in your FieldFormatter class OUT, and change FieldFormatter to an "interface". Create XMLFieldFormatter and HTMLFieldFormatter that 'implements' FieldFormatter. Put the code that was in FieldFormatter into the appropriate *FieldFormatter object and create the other one with new code. i.e. the toML() method in FieldFormatter. Only looks like a function prototype, it contains no code, and is only used to call the derived class. Suddenly, polymorphism! User code: Field obj = new Field(); obj.setFormatter(new XMLFieldFormatter()); OR obj.setFormatter(new HTMLFieldFormatter()); String theString = obj.toML(); public interface FieldFormatter { public String toML(); /* note, no code in an interface */ } public class HTMLFieldFormatter implements FieldFormatter { public String toML() { return "<p>" + blah + </p>; } } public class XMLFieldFormatter implements FieldFormatter { public String toML() { return "<xml>" + blah + "</xml>"; } } public class Field { protected FieldFormatter formatter = null; (not sure if this is correct) ... public void setFormatter(FieldFormatter fieldFormatter) { formatter = fieldFormatter; } public String toML() { return formatter.toML(); } } "The stuff we call "software" is not like anything that human society is used to thinking about. Software is something like a machine, and something like mathematics, and something like language, and something like thought, and art, and information... but software is not in fact any of those other things." Bruce Sterling - The Hacker Crackdown Fred A. Kulack - AS/400e Java and Java DB2 access, Jdbc, JTA, etc... IBM in Rochester, MN (Phone: 507.253.5982 T/L 553-5982) mailto:kulack@us.ibm.com Personal: mailto:kulack@bresnanlink.net AOL Instant Messenger: Home:FKulack Work:FKulackWrk +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.