EliminateFuzzyModifiers
From APIDesign
(New page: ''Fuzzy'' access modifiers are source of all evil as described at ClarityOfAccessModifiers page. Good message is that we do not need them. Our APIs can be clear enough ...) |
|||
| Line 1: | Line 1: | ||
| - | ''Fuzzy'' access modifiers are source of all evil as described at [[ClarityOfAccessModifiers]] page. Good message is that we do not need them. Our [[API]]s can be [[Clarity|clear]] enough with use of following easy steps | + | ''Fuzzy'' access modifiers are source of all evil as described at [[ClarityOfAccessModifiers]] page. Good message is that we do not need them. Our [[API]]s can be [[Clarity|clear]] enough with use of following easy steps. |
| + | == Public Abstract == | ||
| + | |||
| + | Imagine that there is a class with a single '''public''' '''abstract''' method like in this example: | ||
| + | |||
| + | <source lang="java" snippet="sidemeanings.PublicAbstract.Dirty"/> | ||
| + | |||
| + | This indeed violates the [[ClarityOfAccessModifiers|clarity rules]] and in many cases [[API]] designers may wish to eliminate it. The change is simple. Just split the method into two: | ||
| + | |||
| + | <source lang="java" snippet="sidemeanings.PublicAbstract.Clean"/> | ||
| + | |||
| + | Now both methods use single meaning access modifiers, so the so wanted [[clarity]] is achieved. Moreover the usage of such [[API]] is made complex. Compare the original snippet with classical modifier: | ||
| + | |||
| + | <source lang="java" snippet="sidemeanings.PublicAbstract.Dirty.test"/> | ||
| + | |||
| + | With the same code rewritten to ''clean'' version with two methods. Everything remains the same, just instead of overriding the final method, one needs to override the ''protected abstract'' one: | ||
| + | |||
| + | <source lang="java" snippet="sidemeanings.PublicAbstract.Clean.test"/> | ||
| + | |||
| + | Eliminiating '''public''' '''abstract''' modifiers is easy, if found desirable. | ||
TBD: Meanwhile see the book's [[Cooperating_with_Other_APIs|Chapter 10]], Cooperating with Other APIs where this topic is discussed. | TBD: Meanwhile see the book's [[Cooperating_with_Other_APIs|Chapter 10]], Cooperating with Other APIs where this topic is discussed. | ||
Revision as of 21:24, 25 March 2009
Fuzzy access modifiers are source of all evil as described at ClarityOfAccessModifiers page. Good message is that we do not need them. Our APIs can be clear enough with use of following easy steps.
Public Abstract
Imagine that there is a class with a single public abstract method like in this example:
does not exists: sidemeanings.PublicAbstract.Dirty
This indeed violates the clarity rules and in many cases API designers may wish to eliminate it. The change is simple. Just split the method into two:
does not exists: sidemeanings.PublicAbstract.Clean
Now both methods use single meaning access modifiers, so the so wanted clarity is achieved. Moreover the usage of such API is made complex. Compare the original snippet with classical modifier:
does not exists: sidemeanings.PublicAbstract.Dirty.test
With the same code rewritten to clean version with two methods. Everything remains the same, just instead of overriding the final method, one needs to override the protected abstract one:
does not exists: sidemeanings.PublicAbstract.Clean.test
Eliminiating public abstract modifiers is easy, if found desirable.
TBD: Meanwhile see the book's Chapter 10, Cooperating with Other APIs where this topic is discussed.
Follow
