InvisibleAbstractMethod
From APIDesign
(New page: Having an '''abstract''' class with package private ''abstract'' method effectively prevents anyone to subclass it. That can be considered as good [[:APIDesignPatterns|API design patte...) |
|||
| Line 1: | Line 1: | ||
Having an '''abstract''' class with package private ''abstract'' method effectively prevents anyone to subclass it. That can be considered as [[good]] [[:APIDesignPatterns|API design pattern]], especially if that is something one starts with. | Having an '''abstract''' class with package private ''abstract'' method effectively prevents anyone to subclass it. That can be considered as [[good]] [[:APIDesignPatterns|API design pattern]], especially if that is something one starts with. | ||
| - | However it can also turn into a huge anti-pattern. Adding first package private ''abstract'' method into an abstract class is in fact an incompatible change. If the class used to be subclassable before, this prevents | + | However it can also turn into a huge anti-pattern. Adding first package private ''abstract'' method into an abstract class is in fact an incompatible change. If the class used to be subclassable before, this prevents the subclassing and as such classes that used to compile may compile no longer. |
| - | The hidden catch is that tools like [[Sigtest]] are unlikely to catch this situation, as they don't care about package private methods! | + | The hidden catch is that tools like [[Sigtest]] are unlikely to catch this situation, as they don't care about package private methods! Some people complained about unnecesary complexity of various [[OOP]] access modifiers - and they were likely right, but this case worse (from the point of an [[API]] designer) - a change to an implementation detail may change the published [[API]]s! |
[[TBD]] | [[TBD]] | ||
Revision as of 23:26, 9 March 2012
Having an abstract class with package private abstract method effectively prevents anyone to subclass it. That can be considered as good API design pattern, especially if that is something one starts with.
However it can also turn into a huge anti-pattern. Adding first package private abstract method into an abstract class is in fact an incompatible change. If the class used to be subclassable before, this prevents the subclassing and as such classes that used to compile may compile no longer.
The hidden catch is that tools like Sigtest are unlikely to catch this situation, as they don't care about package private methods! Some people complained about unnecesary complexity of various OOP access modifiers - and they were likely right, but this case worse (from the point of an API designer) - a change to an implementation detail may change the published APIs!
Follow
