代码之家  ›  专栏  ›  技术社区  ›  Chris

我的内部API类应该都在一个包中吗?

  •  8
  • Chris  · 技术社区  · 14 年前

    我正在努力包装一个公共消费的API。因此,我试图限制只向那些我希望公开和支持的方法公开的方法。当然,在这下面有许多有限的访问方法。

    问题是我有很多内部代码需要访问这些受限的方法而不公开这些方法。这就产生了两个问题:

    • 我无法创建接口 像这样在课堂间交流 会让这些成为我的内在方法 公众。
    • 我无法访问受保护或默认 方法,除非我把 我的内部课程在同一个 包裹。

    所以,我在干净隔离的包中有大约70或80个内部类,但是有过多的允许访问修饰符。你会说一个包是两个恶魔中较小的一个,还是有更好的方法能够在保持更细粒度的包的同时掩盖我的内部方法?

    我有兴趣在这里找到最佳实践。

    我已经知道了 This

    3 回复  |  直到 11 年前
        1
  •  7
  •   Community holdenweb    7 年前

    对于您的问题,有两种解决方案不涉及将所有类保持在同一个包中。

    首先是使用朋友访问器/ Friend Package 模式描述见(实用API设计,Tulach 2008)。

    第二个是使用OSGi。有篇文章 here 解释OSGi是如何实现这一点的。

    相关问题: 1 , 2 , 3 4 .

        2
  •  2
  •   stacker    14 年前

    一个例子是 Servlet API 正如您看到的,它们将通用servlet API和HTTP分为两个包。

    如果在 api.jar implementation.jar 您可以使用API.jar用户看不到的实现接口。 如果类的对象不管其包是什么,都必须以任何方式协作,那么方法当然必须是可见的(至少在实现中是可见的)。

        3
  •  1
  •   manuel aldana    14 年前

    是的,您只是无法保护内部实现人员不被访问。有一些技术(如OSGi)在运行时/应用程序启动期间提供解决方案。这是一个Java语言设计的模块化缺陷(但由于下兼容,以后很难添加)。

    我喜欢将公开可见的工件添加到 /API 包装和内部构件 内部的 . 最后你会得到。

    
    # this package is allowed to be accessed by api-users
    com.foo.users.api
    # this is completely internal logic (api implementation)
    # should only be touched by the api-module itself.
    com.foo.users.internal
    
    

    这样您就有了清晰的分离,还可以运行静态代码分析代码规则。

    像上面提到的servlet API一样,您甚至可以将API和impl进一步拆分到不同的jar中。但这涉及到更多的构建生命周期和维护模块的工作,所以我只会在完整的运行时工件分割有意义的情况下进行(就像在JSR规范和IMPL中一样)。