java - 按功能打包好不好？

Question

最近我发现了这个 javalobby 帖子 http://java.dzone.com/articles/how-changing-java-package关于按功能打包java代码。

我喜欢这个想法，但我对这种方法几乎没有疑问。我问了我的问题，但没有得到满意的答复。我希望 StackOverflow 上的人能澄清我的问题。

我喜欢按功能打包的想法，它大大减少了在编码时跨包移动的时间，所有相关的东西都将放在一个地方(包)。但是不同包中的服务之间的交互呢？

假设我们正在构建一个博客应用程序，并且我们将所有与用户相关的操作( Controller /服务/存储库)放在 com.mycompany.myblog.users 包中。以及 com.mycompany.myblog.posts 包中的所有博客文章相关操作( Controller /服务/存储库)。

现在我想显示用户个人资料以及他发布的所有帖子。我应该从 myblog.users.UserController.showUserProfile() 调用 myblog.posts.PostsService.getPostsByUser(userId) 吗？

包之间的耦合呢？

此外，无论我在何处阅读有关按功能打包的信息，每个人都说这是一个很好的做法。那么为什么很多书籍作者甚至框架都鼓励分层分组呢？只是想知道:-)

Answer 1

看看鲍勃叔叔的Package Design Principles .他解释了这些原则背后的原因和动机，我在下面进行了详细说明:

一起重用的类应该打包在一起，以便可以将包视为一种可供您使用的完整产品。那些一起重用的应该与那些不被重用的分开。例如，您的 Logging 实用程序类不一定与您的文件 io 类一起使用。因此，将所有日志分别打包。但是日志类可以相互关联。因此，创建一种完整的日志记录产品，例如，为了获得更好的名称 commons-logging 将其打包在一个(可重)使用的 jar 中，并为 io 实用程序创建另一个单独的完整产品，再次为了更好的名称，例如 commons- io.jar。 如果您更新说 commons-io 库以说支持 java nio，那么您可能不一定要对日志库进行任何更改。所以把它们分开比较好。

现在，假设您希望您的日志记录实用程序类支持结构化日志记录，例如通过 splunk 等工具进行某种日志分析。您的日志记录实用程序的某些客户端可能想要更新到您的较新版本；其他一些可能不会。因此，当您发布新版本时，将所有需要并重用的类打包在一起进行迁移。因此，您的实用程序类的某些客户端可以安全地删除旧的 commons-logging jar 并移至 commons-logging-new jar。其他一些客户仍然可以使用旧 jar。但是，不需要客户端同时拥有这两个 jars(新旧)，因为您强制他们使用一些用于旧打包 jar 的类。

避免循环依赖。 a 依赖于 b； b 在 c 上；条件;但 d 取决于 a。这种情况显然令人望而却步，因为定义层或模块等将非常困难，而且您不能相对于彼此独立地改变它们。

此外，您可以打包您的类，这样如果一个层或模块发生更改，其他模块或层不必更改。因此，例如，如果您决定从旧的 MVC 框架升级到 rest API 升级，那么可能只有 View 和 Controller 需要更改；你的模型没有。