我希望大家都同意，类的方法应该很小，并且只有很少的依赖关系。 这种观点被广泛接受，而对“小”的解释则各不相同。 关于这一点有很多文献。 但是包裹呢？

有些人将包视为名称空间。 因此，包仅仅是允许您为类重用名称的东西！

几年前，我对方法进行了思考：只是用于可重用代码的容器。

今天，我不同意这两种说法。 方法是命名事物，将事物与其余事物分开的非常重要的工具，即使仅被调用一次也是如此。

同样，即使我们忽略名称问题，软件包也起着重要的作用。 软件包将某些功能捆绑在一起。 他们为该功能命名，应该对其进行封装，以便我们重新使用它。 就像方法一样，程序包应具有单一目的。 它可能比方法的目的“更大”，但它仍然应该只做与该目的直接相关的事情。

不幸的是，在许多项目中，效果并不理想。

这是一个挑战。 从当前项目中随机选择一个软件包。 对于此软件包，请回答以下问题

• 该软件包的目的是什么？ 请使用一个简单的句子。 这句话与包裹名称相符吗？
• 遍历该程序包的类，它们是否都共同努力以达到该类的目的？ 还是那里偶然出现的课程？
• 遍历系统的所有其他类。 他们都不关心包裹的单一用途吗？ 还是有一些类在您应该查看的包中真正浮动的其他地方？
• 如果您在下一个项目中的同事需要基本相同的软件包，那么从您的代码库中提取该软件包并将其构建为独立的jar将有多困难？

以我的经验，上述问题的答案很可能令人沮丧。 他们肯定参与了我合作过的大多数项目。

即使该项目中的类和方法合理干净。

这是为什么？

我认为原因是程序包的问题不如方法或类明显。 如果某个方法跨越整个监视器，则您每次都会看到使用该方法的所有时间。 而且由于该方法很长，因此可能需要做很多工作。 类相同。 但是跟套餐不同。 我花了一整天的时间编写代码，却不看包装里面的东西。 我使用快捷方式和基于名称的搜索打开类，而无需查看包内部。

因此，您不会注意到与完全不同的问题相关的类放在一个包中。 您不会注意到包中的类数超过了任何合理的阈值。

如果涉及到最后一个问题，那么关于依赖关系的问题将变得非常丑陋。 软件包还依赖其他哪些软件包？ 哪个类包含该依赖项？ 对于此类问题的工具支持非常有限。 而且问题只会在项目后期才问到，也许是当产生了一个姊妹项目时，该项目应该重用一些代码库，因此应该在一个通用的基础项目中移动。

由于我去过几次，所以我建议在项目开始时使用JDepend或Dependency Finder进行一些测试：

• 包之间没有循环依赖
• 每个包的最大类数
• 固定的命名架构，例如<domain>。<project>。<module>。<layer>。<package-of-package-name>
• 模块之间的依赖关系的固定方向（模块是垂直切片，通常基于某些域概念）
• 层之间的依赖关系的固定方向（gui，表示，域，持久性是典型示例）

但请注意：这些测试往往很难保持满意。 但是，如果您付出额外的努力来保持程序包的清洁，则会对应用程序结构产生重大的积极影响。

参考： 关于 Schauderhaft博客上JCG合作伙伴 Jens Schauder的软件包 。