SuperVsInner

From APIDesign

I always felt that there is some clash between the general desire for object oriented reuse and principles of good API design. Proponents of reuse seem to advocate making every method virtual, every class subclassable, every behavior changeable. Those who maintained API of a framework for some time and tried to keep some degree of BackwardCompatibility know that opening up more than planned for will at the end hurt the reuse.

I attribute this to the way subclassing is done in Java or C++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an OOP language which is not flawed this way - Beta. However I never had enough time to learn Beta properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this rotation.

That is why I am thankful to authors of Super and Inner — Together at Last! for explaining everything in the Java terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my ClarityOfAccessModifiers essay). It is named pubment and it is a perfectly fine (from API design perspective) combination of callable and slot which allows augmentation:

Code from SuperInner.java:

public abstract class JavaLikeExample {
  public final int callable() {
    return 1 + theSlot();
  }
 
  protected abstract int theSlot();
}
 

Code from SuperInner.java:

public abstract class BetaLikeExample {
  pubment int callable() {
    int res = inner.callable();
    return res + 1;
  }
}
 

The paper also explains why inner is more suitable for API design. To quote: The overall philosophy of class extension in Java-like languages (using super) is: subclass implementors know better. The philosophy of class extension in Beta-like languages (with inner) is: superclass implementors know better.

Regardless of using Java or Beta style and with the hope to support cluelessness of our API users I want to recommend:

When designing an API, always make sure that you know better than users of your API!

<comments/>