有(Java)包组织的最佳实践吗[[关闭]

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

• 跟随java package naming conventions
• 根据它们的功能角色和业务角色来构造包
  • 根据软件包的功能或模块对其进行细分。例如 com.company.product.modulea
  • com.company.product.module.web 或 com.company.product.module.util 等。
• 如果你的项目很小,就用很少的软件包保持简单。例如 com.company.product.model com.company.product.util
• 请看一些流行的开源项目 Apache projects . 看看他们如何为各种规模的项目使用结构化。
• 在命名时还要考虑构建和分发(允许您在不同的包中分发api或SDK,请参阅servlet api)

我整理包裹 按功能

• beans
• factories
• collections

你错了。

例如,我更喜欢:

• orders
• store
• reports

所以我可以通过 包可见性 . 工厂的订单应该在 订单

简而言之:每个模块/功能一个包,可能有子包。把密切相关的东西放在同一个包裹里。避免包之间的循环依赖关系。

长话短说: I agree with most of this article

我更喜欢先功能后图层,但我想这取决于你的项目。考虑你的力量:

• 
  尽量减少包的依赖性,特别是功能之间的依赖性。
• 团队组织
  在某些组织中,团队处理特性,而在另一些组织中,团队处理层。 这会影响代码的组织方式,使用它来形式化api或
• 部署和版本控制
  把所有东西都放到一个模块中进行部署和版本控制 更简单,但更难修复错误。分割东西能使事情变得更好
• 应对变化
  组织良好的代码要比一个大泥球简单得多。
• 大小 (人员和代码行)
  规模越大,就越需要正式化/标准化。
• 重要性/质量
  有些代码比其他代码更重要。api应该比实现更稳定。因此需要明确区分。
• 
  局外人应该可以知道代码是关于什么的,以及从哪里开始阅读包树。

例子:

com/company/module
  + feature1/
    - MainClass          // The entry point for exploring
    + api/               // Public interface, used by other features
    + domain/
      - AggregateRoot
      + api/             // Internal API, complements the public, used by web
      + impl/ 
    + persistence/       
    + web/               // presentation layer 
    + services/          // Rest or other remote API 
    + support/            
  + feature2/
  + support/             // Any support or utils used by more than on feature
    + io
    + config
    + persistence
    + web

这只是一个例子。很正式。例如,它为 . 通常情况下,这是不需要的,但可能是一个好主意,如果使用不同的人。您可以让内部API扩展公共。

我不喜欢“impl”或“support”名称,但它们有助于区分不太重要的内容和重要的内容(域和API)。在命名方面,我喜欢尽可能具体。如果您有一个名为“utils”的包,其中包含20个类,请移动 StringUtils 为了支持/string, HttpUtil 支持/http等。

在Java中组织包以及包中包含的内容方面是否有最佳实践?

不是真的。有很多想法,很多观点,但真正的“最佳实践”是运用你的常识!

(请阅读 No best Practices 了解“最佳实践”和推广人员的观点。)

(包/模块中类之间的循环依赖关系很好,但包间循环往往会使您难以理解应用程序的体系结构,并且可能成为代码重用的障碍。特别是,如果您使用Maven,您会发现循环的包间/模块间依赖性意味着整个互连的mess必须是一个Maven工件。)

我还要补充一点 是 一个被广泛接受的包名最佳实践。也就是说,你的包名应该以你组织的域名开始,顺序相反。如果您遵循这个规则,您就可以减少由于您的(完整)类名与其他人的类名冲突而导致问题的可能性。

我见过一些人提倡“按功能包”而不是“按层包”,但我多年来使用了不少方法,发现“按层包”比“按功能包”好得多。

• 促进创建可重用的框架(同时具有两个模型的库) 和UI方面)
• 更多。。。

Java Package Name Structure and Organization 但我的标准包结构是:

哪里:

revdomain公司 反向域,例如com.mycompany

模块类型

模块名

层 [模型| ui |持久性|安全性等]

例如,wicket、jsp、jpa、jdo、hibernate(注意:如果层是model,则不使用)

特征

例如,会计

例如,折旧

*如果moduleType是一个应用程序,那么有时“app”被省略了,但是将它放在那里可以使包结构在所有模块类型中保持一致。

另一方面,我让一个同事为他所做的几乎每件事创建了一个新的包。他想要的每个不同的MVC都有自己的包,而且MVC集似乎是同一个包中唯一允许的类分组。我记得有一次他有5个不同的包,每个包中只有一个类。我认为他的方法有点极端(当我们无法处理时,团队强迫他减少包数),但是对于一个非平凡的应用程序,将所有内容放在同一个包中也是如此。这是你和你的队友必须为自己找到的一个平衡点。