SuperVsInner

From APIDesign

Revision as of 12:38, 24 February 2010

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.

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 users I'd like to share this advice:

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