逐包特征方法是否良好？

Question

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

我喜欢这个想法,但我对这种方法的问题很少.我问了我的问题,但没有得到满意的答复.我希望StackOverflow上的某个人可以澄清我的问题.

我喜欢逐个功能的想法,它可以大大减少编码时移动包的时间,所有相关的东西都在一个地方(包).但是不同包中的服务之间的交互呢？

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

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

包之间的耦合怎么样？

无论我在哪里阅读有关逐个功能的内容,每个人都说这是一个很好的做法.那么为什么许多书籍作者甚至框架都鼓励按层分组呢？只是好奇知道:-)

Answer 1

看看鲍勃叔叔的包装设计原则.他解释了这些原则背后的原因和动机,我在下面详细阐述:

重复使用的类应该打包在一起,以便可以将包视为一种可供您使用的完整产品.那些重复使用的应该与那些没有重复使用的那些分开.例如,您的日志记录实用程序类不一定与文件io类一起使用.所以打包所有记录它们分开.但是日志记录类可能彼此相关.因此,创建一种完整的产品用于日志记录,例如,为了更好的名称公共 - 记录包装在一个(可重复使用的)罐子和另一个单独的完整产品的io实用程序,再次为了更好的名称,比如公共 - io.jar.如果你更新说commons-io库来说支持java nio,那么你可能不一定要对日志库进行任何更改.因此将它们分开会更好.

现在,假设您希望您的日志记录实用程序类支持结构化日志记录,以便通过splunk等工具进行某种日志分析.您的日志记录实用程序的某些客户端可能希望更新到您的新版本; 其他人可能没有.因此,当您发布新版本时,请将所有需要的类打包并重复使用以进行迁移.因此,您的实用程序类的一些客户端可以安全地删除旧的commons-logging jar并移动到commons-logging-new jar.其他一些客户仍然可以使用旧罐子.但是,不需要客户端同时拥有这些jar(新旧)只是因为你强迫它们为旧的打包jar使用某些类.

避免循环依赖.依赖于b; b; c; 条件; 但是d取决于a.这种情况显然是一种威慑,因为定义图层或模块等非常困难,并且您无法相互独立地改变它们.

此外,您可以打包您的类,以便在图层或模块更改时,其他模块或层不必更改.因此,例如,如果您决定从旧的MVC框架转到其他API升级,那么只有视图和控制器可能需要更改; 你的模型没有.

Answer 2

除了用于包装设计的耦合之外还有许多其他方面我建议看看OOAD原理,特别是包装设计原理,如

REP释放重用等效原则 重用的颗粒是释放的颗粒.

CCP共同关闭原则 一起更改的类被打包在一起.

CRP共同重用原则 将一起使用的类打包在一起.

ADP非循环依赖关系原则 包的依赖关系图必须没有循环.

SDP稳定的依赖原则取决于稳定性.

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

有关更多信息,你可以阅读的书 "敏捷软件开发,原则,模式与实践"

Answer 3

我个人喜欢"按功能打包"的方法,尽管你需要对绘制包边界的位置应用相当多的判断.在许多情况下,这当然是一种可行且明智的方法.

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

只要它使用设计良好的公共接口就可以将"博客帖子"包调用到"用户"包中.

如果你采用这种方法,那么可以提出一个很重要的建议:对你的依赖关系进行非常深思熟虑,特别是避免使用包之间的循环依赖关系.一个好的设计应该看起来像一个依赖树 - 具有更高级别的功能区域取决于一组依赖于效用函数库等的公共服务.在某种程度上,这将开始看起来像前面的建筑"层"结束打包到后端服务的包.