🚀 go-pugleaf

A few days ago I gave a couple programmers my latest stack of UML reports,
plus stubbed classes and interfaces produced with Rational Rose to
implement.  For nearly 2 days they tried and tried, but couldn't get the
code to work right.  After I spent half of last night looking at the 30 -odd
classes making up this section, I started to think my years in OO design
taught me nothing.  I eventually simplified the problem, making another
project and tested "The Rules".  Here's the code I wrote:

// FILE:  SuperInterface.java
package OOTest;
public interface SuperInterface {
  public void print(SuperParm superParm);
}


// FILE: SubInterface.java
package OOTest;
public interface SubInterface extends SuperInterface{
}


// FILE: SuperClass.java
package OOTest;
public class SuperClass implements SuperInterface {
  public SuperClass() {
  }
  public void print(SuperParm superParm){
    System.out.println("SuperClass Print() called");
  }
}

//FILE: SubClass.java
package OOTest;
public class SubClass extends SuperClass implements SubInterface{
  public SubClass() {
  }
  public void print(SubParm subParm){
    System.out.println("SubClass Print() called");
  }
}

//FILE: SuperParm.java
package OOTest;
public class SuperParm {
  public SuperParm() {
  }
}

//FILE: SubParm.java
package OOTest;
public class SubParm extends SuperParm {
  public SubParm() {
  }
}

//FILE: ClientCode.java
package OOTest;
public class ClientCode {
  SubParm subParm = new SubParm();
  SubInterface subInterface = new SubClass();
  public ClientCode() {
    subInterface.print(subParm);
  }
  public static void main(String[] args) {
    new ClientCode();
  }
}


Now, I throught logically that the output to this program would be:
"SubClass Print() called"

But, no... the output is "SuperClass Print() called".  It turns out that I
have to override the print method in the SubInterface interface with:
public void print(SubParm subParm);
Now, why must I have to explicitly override this method?  It's like Java
automatically casts my interface and the parameter to the super just because
print() is only defined in the SuperInterface!  Hmmm, you'ld think that if I
was ambiguous with my method signitures the compiler would complain.  Now,
imagine these classes being much more complex, utilizing aggregation and
creation patterns, with many methods defined in several interfaces.  This
was terribly hard to debug!!  Yes, we were missing one line it seems in an
interface.  Ever try to "debug" interfaces with JBuilder?  Hmm, I know I'm
tired having stayed up all last night, but I used to think I knew object
oriented design... now I'm not so sure :-(

If anyone knows "The Rules" I thought I knew about this, I'd love to hear
from you!