EliminateFuzzyModifiers

From APIDesign

Revision as of 05:20, 26 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.

The examples on this page are slightly enhanced to those discussed Chapter 10, Cooperating with Other APIs, where this topic is deeply discussed too.

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

Eliminating public abstract modifiers is easy, if found desirable.

Protected

protected methods are also said to have double meaning]. They can be overriden, plus they can carry some implementation for subclasses to call just like in this example:

does not exists: sidemeanings.Protected.Dirty

Similarly like in previous case, this fuzziness can be eliminated by splitting the method into two:

does not exists: sidemeanings.Protected.Clean

The expressive power of such API remains unchanged. Once can still rewrite code that is using the old version:

does not exists: sidemeanings.Protected.Dirty.test

into code written against new version quite easily:

does not exists: sidemeanings.Protected.Clean.test

Just instead of calling super.increment() you need to delegate to the protected final defaultImplementation. The rest of the code stays the same. It is so easy to clarify purpose of protected methods!

Public

The plain public modifier has in fact even more meanings. Just writing:

does not exists: sidemeanings.Public.Dirty

may actually mean three different things. In the process of cleaning the meaning we thus need to split the method in following way:

does not exists: sidemeanings.Public.Clean

Again this does not make any use more complex. The old test:

does not exists: sidemeanings.Public.Dirty.test

needs just two modifications - name of overriden method is different and instead of calling super implementation, we call the default one:

does not exists: sidemeanings.Public.Clean.test

Getting rid of multi-meaning public modifiers is easy too.

Complains?

TBD: Complex? Not that much, moreover correct.

TBD: Hard for reader of the API. True: Split into different classes Chapter 10, Cooperating with Other APIs

TBD: Allows pre/post conditions. E.g. enforcing consistency of an API