（Java）包组织是否有最佳实践？ [英] Are there best practices for (Java) package organisation?

问题描述

不久前，我在这里看到了一个关于java包的细粒度组织的问题。例如，my.project.util，my.project.factory，my.project.service等。

A little while ago, I saw a question answered here regarding the fine-grained organisation of java packages. For example, my.project.util, my.project.factory, my.project.service etc.

我现在找不到它，所以我也可以提出问题。

I can't find it now, so I may as well ask the question.

是否有关于Java程序包组织及其内容的最佳实践？

Are there best practices with regards to the organisation of packages in Java and what goes in them?

如何在Java项目中组织课程？

How do you organise your classes in your Java project?

例如，我正在与一些人合作的项目有一个名为beans的软件包。它最初是一个包含简单豆类的项目，但最终（通过糟糕的经验和缺乏时间）包含所有内容（几乎）。我通过在工厂包中添加一些工厂类（使用创建bean的静态方法的类）来清理它们，但我们有其他类来执行业务逻辑，而其他类则执行简单处理（不使用业务逻辑），例如检索来自属性文件的代码消息。

For instance, a project I'm working on with a few people has a package called beans. It started out being a project containing simple beans, but has ended up (through poor experience and lack of time) containing everything (almost). I've cleaned them up a little, by putting some factory classes in a factory package (classes with static methods that create beans) but we have other classes that do business logic and others that do simple processing (not with business logic) like retrieving a message for a code from a properties file.

您的想法和意见表示赞赏。

Your thoughts and comments are appreciated.

推荐答案

包装组织或包装结构通常是一个激烈的讨论。以下是包命名和结构化的一些简单指南：

Package organization or package structuring is usually a heated discussion. Below are some simple guidelines for package naming and structuring:

• 关注java 包命名约定


• 根据包的功能和业务角色构建包
  
  
  
  
  • 根据功能或模块细分包。例如 com.company.product.modulea
  
  
  • 进一步细分可以基于软件中的图层。但是如果你的包中只有几个类，那就不要过分了，那么把所有东西放在包里都是有意义的。例如 com.company.product.module.web 或 com.company.product.module.util etc。
  
  
  • 避免过度使用结构化，IMO避免单独包装异常，工厂等，除非迫切需要。
  
  
  • Follow java package naming conventions
  • Structure your packages according to their functional role as well as their business role
    • Break down your packages according to their functionality or modules. e.g. com.company.product.modulea
    • Further break down could be based on layers in your software. But don't go overboard if you have only few classes in the package, then it makes sense to have everything in the package. e.g. com.company.product.module.web or com.company.product.module.util etc.
    • Avoid going overboard with structuring, IMO avoid separate packaging for exceptions, factories, etc. unless there's a pressing need.

    经过一些实验和试验后，你应该能够想出一个你觉得舒服的结构。不要只关注一个约定，对变化持开放态度。

    After a few experiments and trials you should be able to come up with a structuring that you are comfortable with. Don't be fixated on one convention, be open to changes.

    这篇关于（Java）包组织是否有最佳实践？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！