我正在寻找防止内部泄漏到API的不同方法。这是一个很大的问题,因为一旦这些内部漏洞进入API;您可以遇到意外的不兼容问题或进入冻结内部。
最简单的方法之一就是使用不同的Maven模块;一个带有API的模块和一个带有实现的模块。这样就无法从API中公开实现。
不幸的是,不是每个人都同意这是最好的方法;但还有其他选择吗?例如,使用checkstyle或其他“架构检查”工具?
PS:我们的Java 9无法使用,因为我们即将升级到Java 8,这将是未来一段时间内支持最低的版本。答案 0 :(得分:1)
遵循checkstyle的想法,应该可以设置检查源文件中的import语句的规则。
Checkstyle内置了对该内容的支持,特别是IllegalImport和ImportControl规则。
如果公包和内部类可以通过包名轻松分隔,这当然最有效。
IllegalImport
的想法是在checkstyle中配置TreeWalker,它只查看您的API源,并且不包括从内部包中的导入。
另一方面,使用ImportControl
规则,您可以在单独的XML文件中为整个应用程序/模块定义非常详细的访问规则。
答案 1 :(得分:0)
It is standard in Java to define an API using interfaces and implement them using classes. That way you can change the "internals" however you want and nothing changes for the user(s) of the API.
答案 2 :(得分:0)
一种替代方法是为API和实现提供一个模块(Jar文件)(但是,再次,它是API还是任何类型的库?)。在内部通过使用包来分隔类和接口,例如com.acme.stuff.api
和com.acme.stuff.impl
。在后一个包protected
或仅package-protected
中创建类非常重要。
软件包名称不仅显示了消费者的开发人员,嘿,这是实现",也不可能在内部使用任何内容(为简单起见,此时省略反思)
但同样:这违反了API的想法,因为通常可以更改实现。使用这种方法,无法将API与实现分开,因为两者都在同一模块中。
如果它只是隐藏库的内部,那么这是一个(不是一个)可行的方法。
以防你是指一个库而不是一个API,它只暴露了它的前端" (通过使用接口或抽象类等),使用不同的包名称,例如com.acme.stuff
和com.acme.stuff.internal
。当然,适用相同的可见性规则。
另外:这样一个人不需要Checkstyle和其他负担。
答案 3 :(得分:0)
这是一个好的开始:http://wiki.netbeans.org/API_Design
关键点:Do not expose more than you want 显然,API中表达的实现越少,未来的灵活性就越大。可以使用一些技巧来隐藏实现,但仍然提供所需的功能
我认为你不需要任何检查式或类似的东西,只需要一个好的旧的坚固设计和架构就足够了。多态性就是你所需要的。
最简单的方法之一就是使用不同的Maven 模块;一个带有API的模块和一个带有实现的模块。这个 这样就无法从API中公开实现。
是的,我完全同意,尽可能隐藏,在独立项目中分离您的界面。