Java 架构编码约定答案

【问题标题】：Java architecture coding conventionsJava 架构编码约定
【发布时间】：2010-01-05 19:59:13
【问题描述】：

我现在在几家不同的公司工作，每个公司对如何命名类和包都有不同的规则。它们每个都有不同的包布局和类之间的工作流程。通过这些经验，我对如何布局项目有了一定的了解；但是，我想要一个关于如何布局项目的更具体的定义。这个问题更多的是关于 uml 而不是命名约定。

我很好奇的是关于以下方面的官方架构定义是什么（我看到助手用作实用程序，管理器用作助手等）。

“类”助手
“类”实用程序
“类”工厂
“班级”经理
简单的“类”
默认“类”
我的“班级”

【问题讨论】：

我不确定这与“架构”有什么关系 - 似乎您只是在询问“可接受的定义”
随意重新命名为更合适的标题
严格来说这不是架构，因为这里没有任何东西应该（理论上！）决定用户体验或产品手册内容。维护细节不应成为产品体验或用户知识的一部分！这真的是设计——但这至少是从建筑师的角度来看的设计，因此可能正确地保留在架构标签下。

标签： java architecture naming-conventions uml

【解决方案1】：

对我来说：

Helper 是一种外观，或者它对特定数据格式进行编码/解码，并且在调用之间没有状态。
实用程序用于编码/解码格式或执行 IO，如果它创建连接，通常不会在调用之间保持连接或保持文件打开。
Manager 类似于 Helper，但在调用之间确实有状态。
Factory 是一个类，它获取或创建然后返回一个对象（自定义对象或 API 对象）。
Simple 和 Default 通常只表示基类。
A 我的“类”往往用于预先设计的想法和代码示例，尽管它有时用于生产代码中，例如用于 MyApplication 和 MyView（主要是命名单例）。

这些类名是事实上的。这些是我最常创造和看到的含义，但经常看到相互矛盾的命名方案和不一致。它们不是正式的设计模式名称，实际上选择这些名称中的任何一个似乎几乎是任意的。有些人用这些名称中的一个来标记他们所有线程安全的类，而用它们中的另一个来标记不属于线程安全的类。

我也经常看到“管理器”名称被赋予使用对象或键执行类似 ORM 的函数的类，或用于仲裁连接的对象。

编辑

我看到一个基于框架构建的应用程序通常具有以下主要对象：

官方进程进入/退出/事件处理存根
一个（单例）应用程序对象（引用分层数据模型，也许还有任务对象）
数据库管理器
网络管理员
UI（根据您的宗教信仰引用或不引用视图模型）
Helper/Utility/Factory 类
各种胶水代码
辅助文件

我认为专注于最大化可测试性和最小化这些接口的表面积比包命名和文件命名更重要；我认为您应该按照自己的鼻子来了解项目的详细故障和命名。出于 SCM 目的将代码拆分为不同的文件对于上述多个项目符号所依赖的共享文件特别重要。

编辑

我经常使用单例、享元、复合、迭代器、备忘录、观察者、状态、策略。我在模块之间和 UI 代码中使用外观、代理、责任链。我偶尔会在复杂的数据系统中使用工厂、原型和构建器，当系统在概念上特别复杂时使用模板和访问者。当行为复杂时，我偶尔会使用适配器、桥接器、工厂、抽象工厂、装饰器。我很少使用解释器，并且在某些情况下我使用调解器来帮助我编写更通用的代码。我个人不喜欢以 GoF 来命名我的课程，但很多人都很乐意这样做，这可能是个好主意，我并不反对这种做法。它可能非常有用，如果它能让人们开心，并且确实有助于让每个人都清楚地了解特定情况下发生了什么，那就太好了。

我只是觉得将我的应用程序对象称为 Singleton、Composite 或 ChainOfResponsibilityLink (?) 感觉不好，并且调用我的网络和数据库代码适配器也感觉不好，所以我称它们为 Managers。在 GoF、Helper 或 Utilities 下，我将很多应该称为 Facades 的东西称为，因为我认为它的含义更清楚。

【讨论】：

+1 因为 GoF 为我们提供了不错的词汇，尽管恕我直言，经理和助手反之亦然，这可能是词汇方面的问题 ;-)

【解决方案2】：

您通常会看到很多这样的术语，但没有任何官方标准。我实际上会说其中一些是不好的做法。很多时候，“helper”和“manager”类是做太多事情的类，并且可以捕捉到应该在其他地方出现的行为。

【讨论】：

我真的同意这一点。似乎大多数人使用 helper 是因为他们不知道应该在哪里放置正确的功能。
写程序代码不一定错。只是它在扩展时存在众所周知的问题。
我喜欢你看到“ApplicationManager”之类的内容和“管理应用程序”的类描述。
哈哈哈，很高兴看到我不是唯一一个不断看到荒谬课程的人
最好的重复名称是基于共享知识的名称。对我来说，这将是基于设计模式的名称。参见 GoF 和 PEAA。不同的框架也有不同的命名约定。对于 .NET，这些在 Cwalina 和 Abrams 的框架设计指南中有详细记录。不确定 Java。

【解决方案3】：

说实话，我不确定您所说的大多数术语是什么意思。如果您在谈论设计模式，那么我相信四人帮 (Design Patterns) 有他们使用的每种模式的图表。如果你在谈论其他事情，你可能把事情复杂化了。

另外，您希望从哪里获得对本身不是官方的术语的“官方”定义？

【讨论】：

谢谢，我去看看。我认为你是对的，我应该在考虑其他任何事情之前更好地理解设计模式。
另一个资源，正如我在另一个答案中评论的那样，是 PEAA（企业架构模式）。也是 Eric Evans 的领域驱动设计。这些资源解释了经过验证的架构方法，并且类命名通常基于所采用的模式的名称。

【解决方案4】：

我认为您不会找到这些术语的“官方”定义，因为它们对不同的人有不同的含义。名称可能很难，因为虽然它们最终是任意的，但拥有一个准确简洁地描述类角色的名称是一个很好的目标。 GoF 设计模式书是一个很好的建议。如果您想要更多以 Java 为中心的东西，您可能还想查看核心 J2EE 模式。

【讨论】：

【解决方案5】：

据我所见，项目的包布局更多地由代码的功能支配，而不是它是哪种类型的类（即 java.awt.image、java.awt.font 而不是 java.awt .utils、java.awt.singletons）。

【讨论】：

不过，他问的不是这个。
我相信他做到了。我可能解释错了，但 OP 询问“如何命名类和包”以及“如何布局项目”
对不起，如果我含糊其辞，我只是提出了包装和布局来为我的问题提供背景信息。我对整体布局（例如 MVC 或其他模式）并不好奇

【解决方案6】：

对于命名包和决定哪些类型的类存在于这些包中，确实没有一个标准。这一切都基于您的喜好以及对您有意义的事情。尽管在小组环境中，包命名和每个包中属于什么类型的类通常会在设计会议期间决定，小组几乎可以通过共识达成决定。或者你可以为一个控制狂工作，什么事情按他们的方式做，什么事情没有做，他们为你做决定。

【讨论】：

【解决方案7】：

我认为任何称为 FooManager 的类在 OO 系统中充其量都是有问题的设计。它们往往是拥有大量状态并保留大量全局变量的地方。

【讨论】：