Java 架构编码约定
我现在在几家不同的公司工作过，每个公司对于如何命名类和包都有不同的规则。它们每个类之间都有不同的包布局和工作流程。通过这些经验，我了解了如何布局项目；但是，我想要一个关于如何布局项目的更具体的定义。这个问题更多的是关于 uml 而不是命名约定。
我很好奇的是关于以下内容的官方架构定义是什么（我已经看到助手用作实用程序，管理器用作助手等）。
- “类”助手
- “类”实用程序
- “类”工厂
- “类”经理
- 简单“类”
- 默认“类”
- 我的“类”
I have been working at a few different companies now and every one has different rules about how to name classes and packages. They each have different package layouts and workflow between classes. Through these experiences I have picked up an understanding of how to layout out a project; however, I would like a more concrete definition of how to layout a project. This question is more about uml than about naming conventions.
What I am curious is what are the official architecture definitions regarding the following (I have seen helpers used as utilities and managers used as helpers etc).
- "class" helper
- "class" utility
- "class" factory
- "class" manager
- simple "class"
- default "class"
- my "class"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
对我来说：
Helper 是一个外观，或者它编码/解码特定的数据格式，并且在调用之间没有状态。
Helper 是一个外观，或者
实用程序用于对格式进行编码/解码或执行 IO，如果它创建连接，通常不会维护连接或在调用之间保持文件打开。
Manager 类似于 Helper，但在调用之间具有状态。
工厂是一种获取或创建然后返回一个对象（自定义对象或 API 对象）的类。
工厂是一种获取
Simple 和 Default 通常仅表示基类。
A 我的“类”倾向于用于飞行前的想法和代码示例，尽管它有时在生产代码中使用，例如用于 MyApplication 和 MyView（本质上是为了命名单例）。
这些类名是事实上的。这些是我最常创建和看到的含义，但经常会看到矛盾的命名方案和不一致的情况。它们不是正式的设计模式名称，实际上，这些名称中的任何一个的选择似乎几乎是任意的。有些人用这些名称之一来标记所有线程安全的类，而用其中另一个名称来标记所有线程安全的类。
我也经常看到“管理器”名称被赋予一个使用对象或键执行类似 ORM 功能的类，或者一个仲裁连接的对象。
编辑
我看到一个基于框架构建的应用程序通常具有以下主要对象：
我认为重点是最大化可测试性并最小化这些文件的表面积接口比包命名和文件命名更重要；我认为你应该根据自己的直觉来了解项目的详细分类和命名。出于 SCM 目的将代码拆分为不同的文件对于以上多个项目所依赖的共享文件尤其重要。
编辑
我通常使用单例、享元、复合、迭代器、备忘录、观察者、状态、策略。我在模块之间和 UI 代码中使用外观、代理、责任链。我偶尔会在复杂的数据系统中使用工厂、原型和构建器，而当系统在概念上特别复杂时，我会使用模板和访问者。当行为复杂时，我偶尔会使用适配器、桥、工厂、抽象工厂、装饰器。我很少使用解释器，在某些情况下我使用中介器来帮助我编写更通用的代码。我个人不喜欢用 GoF 来命名我的类，但很多人都非常乐意这样做，这可能是一个好主意，而且我并不反对这种做法。它非常有用，如果它使人们高兴并且确实有助于每个人清楚特定情况下发生的事情，那就太好了。
我只是觉得将我的应用程序对象称为 Singleton、Composite 或 ChainOfResponsibilityLink（？）感觉不太好，而调用我的网络和数据库代码适配器感觉也不太好，所以我称它们为 Manager。我把很多可能应该被称为“Facade”的东西称为“GoF”、“Helpers”或“Utilities”，因为我认为这样的含义更清楚。
To me:
A Helper is a facade, or it codes/decodes a particular data format and does not have state between calls.
A Utility is for coding/decoding a format or doing IO, and if it creates connections often does not maintain connections or keep files open between calls.
A Manager is like a Helper but does have state between calls.
A Factory is a class that gets or creates and then returns an object (either a custom one or an API one).
Simple and Default often simply mean base class.
A My "class" tends to be for pre-flighting ideas and code examples, though it is sometimes used in production code eg for MyApplication and MyView (essentially to name singletons).
These class names are de facto. These are meanings I create and see most often, but contradictory naming schemes and inconsistencies are often seen. They are not formal design pattern names and in practice the choice of any of these names seems to be almost arbitrary. Some people brand all their classes that are thread-safe with one of these names and those that are not with another of them.
Often too I see a "Manager" name is given to a class that does an ORM like function with objects or keys, or to an object that arbitrates connections.
EDIT
I see an app that's built on a framework as usually having these main objects:
I see focussing on maximising the testability and minimising the surface area of these interfaces as more important than package naming and file naming; I think you should follow your own nose for the detailed breakdowns and naming for your project. The splitting of code into different files for SCM purposes is specially important for shared files depended on by more than one bullet above.
EDIT
I use singleton, flyweight, composite, iterator, memento, observer, state, strategy as a matter of routine. I use facade, proxy, chain of responsibility between modules and in UI code. I occasionally use factory, prototype and builder in complex data systems, and template and visitor when a system is particularly complex conceptually. I occasionally use adapter, bridge, factory, abstract factory, decorator when behaviour is complex. I rarely use Interpreter and I use mediator to help me write more general code in certain cases. I don't personally like to name my classes after GoF but lots of people are very happy to, it can be a good idea and I am not against the practice. It can be very useful and if it makes people happy and it does help make clear to everyone what is going on in a particular instance then that's great.
I just feel that calling my app object a Singleton, Composite or ChainOfResponsibilityLink (?) does not feel good, and that calling my network and database code Adapters does not feel good so I call them Managers. And I call a lot of things that ought to perhaps be called Facades under GoF, Helpers or Utilities because I think it is clearer what is meant.
您通常会看到很多这样的术语，但没有任何官方标准。我实际上想说其中一些是不好的做法。很多时候，“帮助者”和“管理者”类是做太多事情的类，并且涵盖了本应在其他地方的行为。
You generally see a lot of these terms thrown around, but there aren't any official standards on that. I would actually say that some of these are bad practices. A lot of times "helper" and "manager" classes are classes that do too much and are a catch all for behavior that should be elsewhere.
老实说，我不确定您所说的大多数术语是什么意思。如果您正在谈论设计模式，那么我相信四人帮一书（设计模式）有他们使用的每种模式的图表。如果你谈论其他事情，你可能会让事情变得过于复杂。
另外，您希望在哪里获得非官方术语的“官方”定义？
To be honest, I am not sure what you mean by most of these terms. If you are talking about design patterns then I believe the Gang of Four book (Design Patterns) has diagrams of each of the patterns that they use. If you are talking about something else, you might be overcomplicating things.
Also, where would you expect to get an "official" definition on terms that are not themselves official?
我认为您不会找到这些术语的“官方”定义，因为它们对不同的人有不同的含义。名称可能很困难，因为虽然它们最终是任意的，但拥有一个准确而简洁地描述类角色的名称是一个很好的目标。 GoF 设计模式这本书是一个很好的建议。如果您想要更多以 Java 为中心的东西，您可能还想查看核心 J2EE 模式。
I don't think you'll find "official" definitions of these terms because they mean different things to different people. Names can be hard because while they are ultimately arbitrary, having a name that precisely and succinctly describe a class' role is a good goal to have. The GoF Design Patterns book is a good suggestion. You might also want to check out Core J2EE Patterns if you want something more Java-centric.
据我所知，项目的包布局更多地受代码功能的控制，而不是它是什么类型的类（即 java.awt.image、java.awt.font 而不是 java.awt.utils， java.awt.singleton）。
From what I have seen, the package layout of the project is more goverened by the functionality of the code, not which type of class it is (i.e java.awt.image, java.awt.font instead of java.awt.utils, java.awt.singletons).
实际上没有命名包和决定这些包中存在哪些类型的类的标准。这完全取决于您的喜好以及对您有意义的内容。尽管在小组环境中，包命名以及每个包中属于什么类型的类通常是在设计会议期间决定的，在设计会议中，小组可以通过协商一致来达成决定。或者你可以为一个控制狂工作，什么事情按他们的方式进行或不按他们的方式进行，他们会为你决定。
There really isn't a standard for naming packages and deciding what types of classes live in those packages. It's all based on your preferences and what makes sense to you. Although in a group environment package naming and what types of classes belong in each package would typically be decided during design meetings where the group can reach a decision pretty much by consensuses. Or you could just work for a control freak that what things done their way or no way and they decide for you.
我认为任何称为 FooManager 的类在面向对象系统中充其量都是有问题的设计。它们往往是保存大量状态和大量全局变量的地方。
I think any class called a FooManager is at best questionable design in an OO system. They tend to be places were tons of state and lots of global variables are kept.