按功能打包是否良好？

Question

最近，我遇到了有关javajava的博客文章http://java.dzone.com/articles/how-changing-java-
package，其中
介绍了按功能打包Java代码。

我喜欢这个主意，但是对于这种方法我没什么疑问。我问了我一个问题，但没有得到满意的答复。我希望StackOverflow上的人可以澄清我的问题。

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

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

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

封装之间的耦合又如何呢？

同样，无论我在何处阅读按功能打包，每个人都说这是一个好习惯。那么，为什么许多书作家甚至框架鼓励按层次分组？只是想知道:-)

Answer 1

看看Bob叔叔的包装设计原则。他解释了这些原则背后的原因和动机，我在下面对此进行了详细阐述：

应该将一起重用的类打包在一起，以便可以将打包包视为可供您使用的完整产品。一起重用的那些应该与那些没有重用的那些分开。例如，您的Logging实用程序类不必与文件io类一起使用。因此，将所有日志记录分别打包。但是日志记录类可能彼此相关。因此，请创建一种用于日志记录的完整产品，例如，想要一个更好的名称commons-
logging包，将其包装在（可重用）jar中，并创建另一个单独的完整产品用于io实用程序，再一次是为了寻求更好的名称，例如commons-
io.jar。如果将“ commons-io”库更新为“支持java nio”，那么您可能不一定要对日志记录库进行任何更改。因此，将它们分开会更好。

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

避免循环依赖。a依赖b; b对c 条件; 但d取决于a。该场景显然令人望而却步，因为很难定义层或模块等，并且您不能相对于彼此独立地进行更改。

同样，您可以打包您的类，以使如果某个层或模块发生更改，则不必一定更改其他一个或多个模块。因此，例如，如果您决定从旧的MVC框架升级到其余的API，则仅视图和控制器可能需要更改。您的模型没有。