你是否遵循包装中的任何指南（java）？

Question

您是否遵循java打包中的任何设计指南？

适当的包装是设计技巧的一部分吗？有没有关于它的文件？

编辑：包如何相互依赖？，循环包是不可避免的？，而不是关于jar或war文件。

Answer 1

我尝试遵循的方法通常如下：

1. 拥有合理尺寸的包裹。少于3个班级很奇怪。少于10是好的。超过30是不可接受的。我对此通常不是很严格。
2. 包之间没有依赖循环。这个很难，因为许多开发人员很难找到任何方法来保持依赖周期免费。但这样做可以在代码中梳理出许多隐藏的结构。思考代码的结构变得更容易，并且更容易进化。
3. 定义图层和模块以及它们在代码中的表示方式。我最终会以<domain>.<application>.<module>.<layer>.<arbitrary substructure as needed>作为包名称的模板
4. 层之间没有循环;模块之间没有循环。

为了避免周期，必须进行检查。许多工具都这样做（JDepend，Sonar ......）。不幸的是，他们找不到修复周期的方法。这就是我开始研究Degraph的原因，它可以通过可视化类，包，模块和层之间的依赖关系来帮助解决这个问题。

Answer 2

打包通常是关于发布管理，一般准则是：

• 一致性：当您向集成，预生产或生产环境发布多个交付时，您希望它们以完全相同的方式组织（或“打包”）

  < / LI>

• 少量文件：当您必须将一组文件从一个环境复制到另一个环境时，如果数量合理，您希望尽可能多地复制（10-每个组件最多可以交付20个），你可以复制它们（即使这些文件的大小很重要）

所以你想为每个交付定义一个共同的结构，如：

aDelivery/
    lib // all jar, ear, war, ...
    bin // all scripts used to launch your application: sh, bat, ant files, ...
    config // all properties files, config files
    src // all sources zipped into jars
    docs // javadoc zipped 
    ...

另外，所有这些公共目录结构应存储在一个公共存储库（VCS或maven存储库，或......）中，以便查询，而无需在每次需要时重建它们他们（如果你只有一个或两个交付组件，你不需要它，但当你有40到60个时......完全重建是不可能的。）

Answer 3

您可以在这里找到很多信息：

What strategy do you use for package naming in Java projects and why?

Answer 4

Java中的打包问题在于它与您想要做的事情关系不大。例如，我喜欢遵循Eclipse约定将包标记为内部的约定，但是我不能用“包”保护级别定义它们的类。