lundi 28 janvier 2019

How to design internal methods access scope?

We have a small lightweight framework with around 20 classes, used by 50+ developers and semi-large code base. To keep the framework small, we've avoided creating too many interfaces, abstract classes, etc. This is a trade-off to speed up adaptation by new developers as well as keep code complexity low.

So we do not utilize internal/external interfaces or heavy use of factory classes. We rely on a few classes with public/private methods to define scope. However sometimes methods have to be public but only be accessible to the framework and not the developer.

Example:

public class Logger
    public boolean isDebugEnabled() {...}
    public void enableDebug() {...}

enableDebug is an "internal" framework method and is documented with "Do not use - Internal class". The method cannot be private nor at package scope due to framework structure.

Once in a while a developer will miss the javadoc and invoke an internal method which can produce unexpected results at runtime.

Example:

if (!Logger.isDebugEnabled) {
    Logger.enableDebug(); // screw the javadoc - i'm enabling debug logging
}

The framework team is thinking the best approach is to name them following a certain convention. This will not introduce compile-time safety, but decrease error probability.

Example:

public void enableDebugInternal() 

is more precise than

/**
* Internal method - do not use
*/
public void enableDebug() 

Can you recommend a better approach ? Preferably something that provides compile-time safety

Aucun commentaire:

Enregistrer un commentaire