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

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

---

这是好事还是坏事

当然，这是主观的，但我通常更倾向于选择包含至少3-4个类，但不超过13-15个类的包。这样可以更好地理解，同时又不会使项目变得混乱。但对于其他人来说，情况可能会有所不同。

---

如果一个包增长超过13-15个类，就会出现一个子包。

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

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

---

希望这能有所帮助。

在我看来，这是一件坏事，尽管在可维护性方面，这并不是真正的阻碍

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

---

可以说，它有助于模块化与“包私有”作用域相结合。但反过来，你也可以说过度包装实际上恰恰相反；i、 e.强迫您使用

public

，如果您没有那么细粒度/迂腐的话，您就不必这样做。

一个特定包中最终出现的类型的实际数量并不那么重要。这就是你如何得到你的包结构

抽象（“what”而不是“how”，本质上是“public”API）、耦合（一个包对其他包的依赖程度）和内聚（一个包中的功能相互关联程度）等更为重要

包装设计的一些指导原则（主要来自）如下：

• 包应该形成可重用和可发布的模块
• 软件包应以良好的可重用性为重点
• 避免包之间的循环依赖关系
• 包应仅依赖于更改频率较低的包
• 包的抽象应该与它的更改频率成比例

---

不要试图从头开始充实整个包结构（您不需要它）。相反，让它不断发展和重构。查看Java源代码的

import

部分，了解移动类型的灵感。不要被只包含一种或几种类型的包分散注意力。

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

所以我尝试保持根包的干净

---

细粒度并不坏，但正如其他人所说，重构通常会产生紧凑的包结构。

包是一个封装单元

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

---

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

还有神奇的数字7+/-2。生理学界已经证明，这是我们理解给定事物能力的基本限制。在我们的大脑需要开始交换之前，我们能在短期记忆中保留多少并同时进行处理。我发现，在编写代码时，这是一个不错的经验法则，即一旦一个包开始超过10个类，就应该认真考虑将其拆分，但如果低于5个包，就真的不值得了。同样适用于菜单组织等方面。看，或者谷歌