design-patterns - 命名类 - 如何避免将所有内容称为“<WhatEver> Manager”？ [关闭](Naming Classes - How to avoid calling everything a “<WhatEver>Manager”? [closed])

Question

A long time ago I have read an article (I believe a blog entry) which put me on the "right" track on naming objects: Be very very scrupulous about naming things in your program.

(很久以前我读过一篇文章（我相信一篇博客文章），它让我在命名对象的“正确”轨道上：非常谨慎地命名程序中的东西。)

For example if my application was (as a typical business app) handling users, companies and addresses I'd have a User , a Company and an Address domain class - and probably somewhere a UserManager , a CompanyManager and an AddressManager would pop up that handles those things.

(例如，如果我的应用程序是（作为一个典型的业务应用程序）处理的用户，公司和地址，我有一个User ，一个Company和一个Address域类-也许某处UserManager ，一个CompanyManager和AddressManager会弹出一个手柄那些事。)

So can you tell what those UserManager , CompanyManager and AddressManager do?

(所以，你可以告诉那些UserManager ， CompanyManager和AddressManager吗？)

No, because Manager is a very very generic term that fits to anything you can do with your domain objects.

(不，因为Manager是一个非常通用的术语，适用于您可以对域对象执行的任何操作。)

The article I read recommended using very specific names.

(我读过的文章建议使用非常具体的名称。)

If it was a C++ application and the UserManager 's job was allocating and freeing users from the heap it would not manage the users but guard their birth and death.

(如果它是一个C ++应用程序，并且UserManager的工作是从堆中分配和释放用户，那么它将不会管理用户，而是保护他们的出生和死亡。)

Hmm, maybe we could call this a UserShepherd .

(嗯，也许我们可以称之为UserShepherd 。)

Or maybe the UserManager 's job is to examine each User object's data and sign the data cryptographically.

(或者， UserManager的工作可能是检查每个User对象的数据并以加密方式对数据进行签名。)

Then we'd have a UserRecordsClerk .

(然后我们有一个UserRecordsClerk 。)

Now that this idea stuck with me I try to apply it.

(现在这个想法一直困扰着我，我尝试应用它。)

And find this simple idea amazingly hard.

(并且发现这个简单的想法非常难。)

I can describe what the classes do and (as long as I don't slip into quick & dirty coding) the classes I write do exactly one thing.

(我可以描述这些类的功能和（只要我不进入快速和脏的编码）我写的类只做一件事。)

What I miss to go from that description to the names is a kind of catalogue of names, a vocabulary that maps the concepts to names.

(我想念从名称到名称的是一种名称目录，一种将概念映射到名称的词汇表。)

Ultimately I'd like to have something like a pattern catalogue in my mind (frequently design patterns easily provide the object names, eg a factory )

(最终，我想在我的脑海里有类似图案目录的东西（通常设计图案很容易提供对象名称，例如工厂 ）)

• Factory - Creates other objects (naming taken from the design pattern)

  (Factory - 创建其他对象（从设计模式中获取命名）)

• Shepherd - A shepherd handles the lifetime of objects, their creation and shutdown

  (牧羊人 - 牧羊人处理物体的生命，它们的创建和关闭)

• Synchronizer - Copies data between two or more objects (or object hierarchies)

  (同步器 - 在两个或多个对象（或对象层次结构）之间复制数据)

• Nanny - Helps objects reach "usable" state after creation - for example by wiring to other objects

  (保姆 - 帮助对象在创建后达到“可用”状态 - 例如通过连接到其他对象)

• etc etc.

  (等等)

So, how do you handle that issue?

(那么，你如何处理这个问题呢？)

Do you have a fixed vocabulary, do you invent new names on the fly or do you consider naming things not-so-important or wrong?

(你有一个固定的词汇表，你是否动态发明新的名字，或者你认为命名的东西不是那么重要或错误？)

PS: I'm also interested in links to articles and blogs discussing the issue.

(PS：我也对链接??到讨论这个问题的文章和博客感兴趣。)

As a start, here is the original article that got me thinking about it: Naming Java Classes without a 'Manager'

(首先，这是让我思考它的原始文章：在没有“经理”的情况下命名Java类)

---

Update: Summary of answers (更新：答案摘要)

Here's a little summary of what I learned from this question in the meantime.

(以下是我在此期间从这个问题中学到的内容的一些总结。)

• Try not to create new metaphors (Nanny)

  (尽量不要创造新的比喻（保姆）)

• Have a look at what other frameworks do

  (看看其他框架做了什么)

Further articles/books on this topic:

(关于这个主题的进一步文章/书籍：)

• What names do you find yourself prepending/appending to classes regularly?

  (你发现自己经常在课前做什么名字？)

• What's the best approach to naming classes?

  (命名类的最佳方法是什么？)

• Book: Design Patterns: Elements of Reusable Object-Oriented Software (Hardcover)

  (书： 设计模式：可重用面向对象软件的元素（精装）)

• Book: Patterns of Enterprise Application Architecture (Hardcover)

  (书： 企业应用程序架构模式（精装）)

• Book: Implementation Patterns (Paperback)

  (书： 实施模式（平装）)

And a current list of name prefixes/suffixes I collected (subjectively!) from the answers:

(以及我从答案中收集的主观名称前缀/后缀的当前列表：)

• Coordinator

  (协调员)

• Builder

  (生成器)

• Writer

  (作家)

• Reader

  (读者)

• Handler

  (处理器)

• Container

  (容器)

• Protocol

  (协议)

• Target

  (目标)

• Converter

  (变流器)

• Controller

  (调节器)

• View

  (视图)

• Factory

  (厂)

• Entity

  (实体)

• Bucket

  (桶)

And a good tip for the road:

(这条道路的好建议：)

Don't get naming paralysis.

(不要命名瘫痪。)

Yes, names are very important but they're not important enough to waste huge amounts of time on.

(是的，名字非常重要，但它们不足以浪费大量时间。)

If you can't think up a good name in 10 minutes, move on.

(如果你不能在10分钟内想出一个好名字，继续前进。)

  ask by community wiki translate from so

Answer 1

I asked a similar question , but where possible I try to copy the names already in the .NET framework, and I look for ideas in the Java and Android frameworks.

(我问了一个类似的问题 ，但在可能的情况下，我尝试复制.NET框架中已有的名称，并在Java和Android框架中寻找想法。)

It seems Helper , Manager , and Util are the unavoidable nouns you attach for coordinating classes that contain no state and are generally procedural and static.

(似乎Helper ， Manager和Util是你为协调不包含状态的类而附加的不可避免的名词，通常是程序性的和静态的。)

An alternative is Coordinator .

(另一种选择是Coordinator 。)

You could get particularly purple prosey with the names and go for things like Minder , Overseer , Supervisor , Administrator , and Master , but as I said I prefer keeping it like the framework names you're used to.

(您可以使用名称获得特别紫色的内容，并选择Minder ， Overseer ， Supervisor ， Administrator和Master ，但正如我所说，我更喜欢将其保留为您习惯使用的框架名称。)

Some other common suffixes (if that is the correct term) you also find in the .NET framework are:

(您在.NET框架中找到的一些其他常见后缀（如果这是正确的术语）是：)

• Builder
• Writer
• Reader
• Handler
• Container