如何设计内部方法的访问范围？

Question

我们有一个小型轻量级框架，包含大约20个类，供50多个开发人员和半大型代码库使用。为了使框架保持较小，我们避免创建过多的接口，抽象类等。这是一个折衷方案，可以加快新开发人员的适应速度，并保持较低的代码复杂性。

因此，我们不使用内部/外部接口或大量使用工厂类。我们依靠一些带有公共/私有方法的类来定义范围。但是，有时方法必须是公开的，但只能由框架而非开发人员访问。

示例：

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

enableDebug是一种“内部”框架方法，并以“请勿使用-内部类”进行记录。由于框架结构，该方法既不能私有也不能在包范围内使用。

开发人员有时会错过javadoc并调用内部方法，该方法可能在运行时产生意外结果。

示例：

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

框架团队认为最好的方法是按照一定的惯例命名它们。这不会引入编译时安全性，但是会降低错误概率。

示例：

public void enableDebugInternal() or _enableDebug() or $enableDebug() 

比

更精确

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

他们正在考虑的另一种选择是将所有内部方法包装到内部类中：

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

您能推荐一种更好的方法吗？ 最好是提供编译时安全性的东西

编辑：原来我正在寻找的是Java中C＃关键字“内部”的设计模式： https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/accessibility-levels

Answer 1

嗯，您几乎回答了自己的问题。您无法更改访问级别，因此几乎必须更改其名称。有点古怪，但是您也可以弃用该方法。 Hamcrest为此{... 3}做了一些……很……有趣的事情。

如果要强制在包外部未使用，则需要在构建过程中进行某种静态分析。如果没有其他选择，我会编写一个Maven插件来查找用法。

最终，如果您有一个需要像包装私有的行为那样工作的公共方法，听起来您的设计是错误的。

无论如何，您都不应编写自己的日志记录外观，尤其是在编写框架时。您应该使用the Matcher interface。