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

Question

随着我从事的项目越来越大，我开始对将类划分为包感到非常不确定。假设项目有很多层，这些层中有接口(interface)和实现，甚至还有更多的子层(组件)。我总是以很多开始有点困惑的包结束。

所以我想知道其他人使用包的方法。你更喜欢有很多包和很少的类，还是有几个包和很多类？您更喜欢将实现与接口(interface)分开吗？等等...一般来说，您使用包的日常习惯以及您的方法的优缺点。

感谢您的帖子。

Answer 1

包旨在帮助您找到东西。

如果他们让它变得比实际更困惑，那么你做的事情就不太对。如果包结构不直观，则实际上比在平面结构中更难找到类。

据我所知，有两种将类组织成包的基本流派:

1. 首先按模块组织。在这里，您的更高级别的包是系统的不同模块，您可以按功能进一步拆分它。
2. 按职能组织。在这里，您首先按功能组织(例如，一个包中的所有 Controller 类，另一个包中的所有数据容器等等)，然后可选择按模块分割。

这两个系统各有利弊，我发现它们大致相同，尽管我更喜欢模块方法。

真正重要的是遵循一个系统，不要将其与另一个系统混合。不要将类硬塞到它们不属于的包中，如果您的新类似乎不属于任何现有类，也不要害怕创建新包。

如果一个包看起来太大了，您可能想要拆分它。但是决定一个包是否应该拆分应该根据其中的类之间是否有明确的概念划分而不是数量来决定。一个只有一个类的包和一个有三十个类的包一样好，如果它们存在的原因很明显的话。

至于分离接口(interface)和实现，首先，我可能会质疑是否需要它们。我经常遇到只有一种合理实现的接口(interface)，这让我质疑它们存在的理由。 (有时有充分的理由，但通常没有。)

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

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