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