【发布时间】：2011-03-03 19:29:43
【问题描述】：
随着我从事的项目越来越大，我开始非常不确定将类划分为包。假设项目有很多层，在这些层中有接口和实现，甚至还有更多的子层（组件）。我总是得到很多包，开始有点混乱。
所以我想知道其他人使用包的方法。你喜欢有很多包很少有类还是有很多包有很多类？您更喜欢将实现与接口分开吗？等等……总的来说，您使用软件包的日常习惯以及您的方法的优缺点。
感谢您的帖子。
【问题讨论】：
标签： java package organization
【发布时间】：2011-03-03 19:29:43
【问题描述】：
包旨在帮助您找到东西。
如果他们让事情变得比现在更混乱，那么你做的事情就不对了。如果包结构不直观，则实际上比平面结构更难找到类。
据我所知，将课程组织成包的基本学校有两种：
- 首先按模块组织。在这里，您的更高级别的包是系统的不同模块，您可以按功能进一步拆分。
- 按职能组织。在这里，您首先按功能进行组织（例如，一个包中的所有控制器类，另一个包中的所有数据容器等等），并可选择按模块对其进行细分。
两种系统各有利弊，我发现它们大致相同，尽管我更喜欢模块方法。
真正重要的是遵循一个系统，不要将它与另一个系统混为一谈。不要将类硬塞到它们不属于的包中，如果你的新类似乎不属于你现有的任何类，也不要害怕创建一个新包。
如果一个包看起来太大了，您可能需要拆分它。但是，是否应该拆分包的决定应该取决于其中的类之间是否存在明确的概念划分，而不是数量。如果很明显它们存在的原因，那么具有单个类的包与具有 30 个类的包一样好。
至于分离接口和实现，首先，我可能会质疑对它们的需求。我经常遇到只有一种合理实现的接口，这让我质疑它们存在的理由。 （有时有充分的理由，但通常没有。）
但是，如果您对给定接口有多个实现，那么是的，我会将它们分开。接口是com.foo.Bar，实现类似于com.foo.bars.CrowBar、com.foo.bars.TaskBar。显然，如果您的实现属于不同的模块，那么您可以将其更改为 com.foo.moduleX.bars.CrowBar 或 com.foo.bars.moduleX.CrowBar，具体取决于您遵循的系统。
重读这一切，听起来确实有点复杂，但可能第一句话是最重要的：不要盲目地遵循打包原则，包应该帮助你找到类，而不是阻碍你。
【讨论】：
-
感谢您详尽的回答。我有一个疑问。模块中的子模块呢，你也为它们创建包吗？例如
com.foo.moduleX.submoduleX.、com.foo.moduleX.submoduleY.
我更喜欢尽可能将我的类和方法的范围限制为私有或包保护（这样它们就不会弄乱 Eclipse 的自动完成功能：），这自动意味着包可以包含相当多的类。
我更喜欢将业务数据对象 (DAO) 与其存储库/检索服务分开，这些服务与业务逻辑对象和视图分开。
由于我倾向于重用逻辑，因此没有交叉依赖关系的相关功能集倾向于放入自己的工件中。当您开始使用 OSGi 和独立服务时尤其方便。
有一点很重要，公开导出的接口（公共接口、枚举和类）需要有一定的相关性，因此包文档显示了一些凝聚力。
【讨论】：