SuperVsInner
From APIDesign
(New page: I always felt that there is some clash between the general desire for object oriented reuse and principles of good API design. Proponents of resuereuse seem t...) |
|||
| Line 1: | Line 1: | ||
| - | I always felt that there is some clash between the general desire for [[OOP|object oriented]] reuse and [[APIDesignPatterns|principles of good API design]]. Proponents of | + | I always felt that there is some clash between the general desire for [[OOP|object oriented]] reuse and [[APIDesignPatterns|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 [[Amoeba Model|hurt the reuse]]. |
| - | I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed | + | 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 [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways | + | That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf 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 '''pubment''' 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. Let me 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''. | ||
| + | |||
| + | In a name of [[cluelessness]] of our users: While designing an [[API]] (regardless whether in [[Java]] or [[Beta]] style), always make sure that you know better than users of your [[API]]! | ||
Revision as of 12:34, 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 pubment 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. Let me 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.
In a name of cluelessness of our users: While designing an API (regardless whether in Java or Beta style), always make sure that you know better than users of your API!
Follow
