按功能打包好不好？ [关闭]

Question

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

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

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

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

现在我想显示用户个人资料以及他发布的所有帖子。我应该从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 升级，那么可能只有视图和控制器需要更改；你的模型没有。

Answer 2

除了封装设计的耦合之外，我建议查看 OOAD 原则，尤其是像

这样的封装设计原则

REP发布重用等效原则重用的粒度就是发布的粒度。

CCP 通用闭包原则 一起改变的类被打包在一起。

CRP 通用重用原则 一起使用的类被打包在一起。

ADP 非循环依赖原则 包的依赖图必须没有循环。

SDP 稳定依赖原则 依赖于稳定的方向。

SAP 稳定抽象原则 抽象随着稳定性而增加。

有关更多信息，您可以阅读book“敏捷软件开发、原则、模式和实践”

Answer 3

我个人喜欢“按功能打包”的方法，尽管您确实需要对在哪里绘制包边界做出大量判断。在许多情况下，这无疑是一种可行且明智的方法。

您可能应该使用公共接口实现包和模块之间的耦合 - 这可以保持耦合的清洁和可管理性。

“博客文章”包调用“用户”包是完全没问题的，只要它使用设计良好的公共接口即可。

如果你采用这种方法，一个重要的建议是：非常考虑你的依赖关系，特别是避免包之间的循环依赖。一个好的设计应该看起来像一棵依赖树——更高级别的功能区域取决于一组公共服务，这些服务依赖于实用函数库等。在某种程度上，这将开始看起来像带有前端的架构“层”-端包调用后端服务。