在Java项目中组织包的优缺点

Question

随着我正在努力的项目变得越来越大，我开始非常不确定将类分成包。假设项目有很多层，在这些层中是接口和实现，甚至更多的子层（组件）。我总是得到很多包装，这些包装开始变得有些混乱。

所以我想知道其他人使用包的方法。你喜欢有很多课程很少的课程或很少有课程的课程吗？您更喜欢将实现与接口分开吗？等等...一般来说，您使用包裹的日常习惯以及您的方法的优点/缺点。

感谢您的帖子。

Answer 1

软件包旨在帮助您查找内容。

如果他们让事情变得更加混乱，那你就没有做得对。如果包结构不直观，实际上找到类比在平面结构中更难。

据我所知，有两个基本的学校组织课程：

1. 首先按模块组织。在这里，您的更高级别的软件包是系统的不同模块，您可以通过功能进一步拆分它。
2. 按功能组织。在这里，您首先按功能组织（例如，一个包中的所有控制器类，另一个包中的所有数据容器，等等），并可选择按模块细分。

两个系统都有利弊，我发现它们非常相似，尽管我更喜欢模块方法。

真正重要的是要遵循一个系统而不要将它与另一个系统混合。如果您的新课程似乎不属于您现有的课程，请不要将自己的课程变成他们不属于的课程，也不要害怕创建新课程。

如果某个软件包似乎变得过大，您可能希望将其拆分。但是，是否应该分割一揽子方案的决定应该考虑其中的类别之间是否存在明确的概念上的划分而不是数字。一个包含单个类的包与包含30个类的包一样好，如果它们显然是为什么它们就在那里。

至于分离接口和实现，首先，我可能会质疑它们的必要性。我经常遇到只有一个合理实现的接口，这让我质疑它们存在的理由。 （有时候有充分的理由，但往往没有。）

但是如果你有一个给定接口的多个实现，那么是的，我将它们分开。界面为com.foo.Bar，实现类似于com.foo.bars.CrowBar，com.foo.bars.TaskBar。显然，如果您的实现属于不同的模块，那么您可以将其更改为com.foo.moduleX.bars.CrowBar或com.foo.bars.moduleX.CrowBar，具体取决于您所关注的系统。

重新阅读这一切，听起来有点复杂，但可能第一句话是最重要的：不要盲目遵循包装原则，包装应该帮助你找到课程，而不是阻碍你。

Answer 2

我更喜欢尽可能将我的类和方法的范围限制为私有或包受保护（因此它们不会混乱Eclipse的自动完成:)这自动意味着包可以包含很多类。

我更喜欢将业务数据对象（DAO）与其存储库/检索服务分开，这些服务与业务逻辑对象和视图是分开的。

没有交叉依赖关系的相关功能集往往会放在他们自己的工件中，因为我倾向于重用逻辑。当你开始玩OSGi和独立服务时，特别方便。

有一点很重要，公开导出的界面（公共接口，枚举和类）需要有些相关，所以包文档显示了一些凝聚力。