我现在在几家不同的公司工作，每个人都有关于如何命名类和包的不同规则。它们各自具有不同的包布局和类之间的工作流程。通过这些经历，我了解了如何布局项目;但是，我想更具体地定义如何布局项目。这个问题更多的是关于uml而不是关于命名约定。
我很好奇的是关于以下内容的官方架构定义是什么（我已经看到帮助器用作实用程序和管理器用作帮助程序等）。
答案 0 :(得分：5)
对我来说：
Helper是一个外观，或者它编码/解码特定的数据格式，并且在调用之间没有状态。
实用程序用于编码/解码格式或执行IO，如果创建连接，则通常不会保持连接或在调用之间保持文件打开。
管理员就像是帮助者，但确实在通话之间有状态。
Factory是一个获取或创建然后返回一个对象（自定义对象或API对象）的类。
简单和默认通常只是指基类。
我的“类”往往是用于预先传播的想法和代码示例，尽管它有时用于生产代码，例如MyApplication和MyView（主要用于命名单例）。
这些类名实际上是。这些是我最常创建和看到的含义，但经常会出现矛盾的命名方案和不一致。它们不是正式的设计模式名称，在实践中，任何这些名称的选择似乎几乎是任意的。有些人用其中一个名称和那些与另一个名称不相关的名称来标记他们所有的线程安全的类。
我经常看到一个“管理器”名称被赋予一个类，该类使用对象或键执行ORM函数，或者对仲裁连接的对象执行。
修改
我看到一个构建在框架上的应用程序通常具有以下主要对象：
我认为专注于最大化可测试性并最小化这些接口的表面积比包命名和文件命名更重要;我认为您应该按照自己的想法为您的项目进行详细的细分和命名。将代码拆分为不同的文件以用于SCM目的对于上面多个项目符号所依赖的共享文件特别重要。
修改
我使用单身，飞重，复合，迭代器，纪念品，观察者，状态，策略作为惯例。我使用Facade，代理，模块之间和UI代码中的责任链。我偶尔会在复杂的数据系统中使用工厂，原型和构建器，在系统特别复杂的概念上使用模板和访问者。当行为复杂时，偶尔会使用适配器，桥接器，工厂，抽象工厂，装饰器。我很少使用Interpreter，我使用mediator来帮助我在某些情况下编写更多通用代码。我个人并不喜欢在GoF之后命名我的课程，但很多人都很高兴，这可能是一个好主意，我并不反对这种做法。它可以是非常有用的，如果它让人们开心，它确实帮助每个人清楚地知道在特定情况下发生了什么，那就太棒了。
我只是觉得调用我的app对象是Singleton，Composite或ChainOfResponsibilityLink（？）感觉不太好，并且调用我的网络和数据库代码Adapters感觉并不好，所以我称之为Managers。我在GoF，Helpers或Utilities下调用了许多应该称为Facades的东西，因为我觉得它更清楚意味着什么。
答案 1 :(得分：4)
你通常会看到很多这些术语被抛出，但没有任何官方标准。我实际上会说其中一些是不好的做法。很多时候“帮助”和“经理”类都是做得太多的类，并且应该是其他地方的行为。
答案 2 :(得分：2)
说实话，我不确定大多数这些术语的含义。如果你在谈论设计模式，那么我相信四人帮书（Design Patterns）有他们使用的每种模式的图表。如果你在谈论其他事情，你可能会过度复杂化。
此外，您希望在哪些地方获得“官方”定义，而这些定义本身并不是正式的？
答案 3 :(得分：1)
我认为你不会找到这些术语的“官方”定义，因为它们对不同的人意味着不同的东西。名字可能很难，因为虽然它们最终是任意的，但是有一个名称可以精确而简洁地描述一个类的角色是一个很好的目标。 GoF设计模式书是一个很好的建议。如果您想要更加以Java为中心的东西，您可能还想查看核心J2EE模式。
答案 4 :(得分：0)
从我所看到的，项目的包布局更加依赖于代码的功能，而不是它的类型（即java.awt.image，java.awt.font而不是java.awt） .utils，java.awt.singletons）。
答案 5 :(得分：0)
确实没有标准用于命名包并确定这些包中存在哪些类型的类。这完全取决于您的偏好以及对您有意义的事情。虽然在组环境中，包命名和每个包中属于哪种类型的类通常会在设计会议期间决定，其中组可以通过共识来达成决策。或者你可以为一个控制狂来工作，那就是他们按照自己的方式做了什么，也没办法做出决定。
答案 6 :(得分：0)
我认为任何一个叫做FooManager的类都是OO系统中最值得怀疑的设计。它们往往是大量的州，并且保留了许多全局变量。