EliminateFuzzyModifiers

From APIDesign

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.