RE: HTML to XML, vice versa

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