具有细粒度的包结构是好事还是坏事？

Question

我最近看了一个Java应用程序，它具有非常细粒度的包结构。许多包只包含一个或两个类和许多子包。许多包也包含比实际类更多的子包。

这是好事还是坏事？

Answer 1

IMO，这是一件坏事，虽然在可维护性方面不是一个真正的阻止。

缺点是它使类更难找到，并且它使包名更加冗长。当您不使用IDE时，前者适用更多。

可以说，它有助于模块化与“包私有”范围相结合。但相反，你也可以说过度包装实际上恰恰相反;即如果你的细粒度/迂腐程度较低，也强迫你使用public你不需要的地方。

Answer 2

最终在一个特定包中的实际类型数量并不重要。这就是你如何达到你的包装结构。

抽象（“什么”而非“如何”，基本上是“公共”API），耦合（包依赖于其他包的程度）和内聚（如何相互关联的是一个包中的功能）之类的东西是更重要的是。

一些包装设计指南（主要来自Uncle Bob）例如：

• 软件包应构成可重复使用且可发布的模块
• 应关注软件包以确保良好的可重用性
• 避免包之间的循环依赖
• 软件包应仅依赖于更改频率较低的软件包
• 包的抽象应与其变化的频率成比例

不要试图从头开始充实整个包装结构（你不需要它）。相反，让它经常进化和重构。查看Java源代码的import部分，了解有关移动类型的灵感。不要被仅包含一种或几种类型的包分散注意力。

Answer 3

我认为更精细的包结构是一件好事。主要原因是它可以帮助最小化您的依赖关系。但是要小心......如果你把实际上属于的东西分解得太多，你最终会得到循环依赖！

根据经验，我通常在包中有一个接口（或一组相关接口）。在子包中，我将实现这些接口（而不是将所有实现都放在同一个包中）。这样客户就可以依赖于感兴趣的界面和实现......而不是所有其他他们不需要的东西。

希望这有帮助。

Answer 4

当然，这是主观的，但我通常更喜欢以一种至少包含3-4个类但不超过13-15个类的方式来决定我的包。它使理解更好，同时不会使项目混乱。但对于其他人来说，它可能会有所不同。 如果一个包增长超过13-15个类，则会要求出现一个子包。

Answer 5

包是一个封装单位。

理想情况下，它通过接口公开公共API，并隐藏包私有类中的实现细节。

因此，包的大小是实现公共API所需的类数。

Answer 6

还有神奇的数字7 +/- 2.在生理界内，已经证明这是我们理解一组特定事物的能力的基本限制。在我们的大脑需要开始交换之前，我们能够在短期记忆和处理过程中保持多少。我在编码时发现这不是一个坏的经验法则，即一旦一个包开始变得超过10个类，就应该认真考虑将它拆分，但是在5个包以下它真的不值得。也适用于菜单组织等。请参阅Millers paper或谷歌。

Answer 7

从头开始编写时，我的方法是开始根包中的所有类（com.example.app1）。当存在一定数量的相互关联的类时，“做一件事”就是创建包的时候了。一段时间后，开发助手类可能会转到通用包（例如com.example.app1.misc，com.example.app1.utils）来卸载根包。

所以我试着保持清洁根包。

细粒度并不差，但正如其他人所说，经常重构会产生紧凑的封装结构。