命名类 - 如何避免将所有内容都称为“<WhatEver>Manager"? [英] Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?

问题描述

很久以前我读过一篇文章(我相信是一篇博客文章)，它让我在命名对象方面走上了正确"的轨道:在你的程序中命名事物时要非常非常谨慎.

例如，如果我的应用程序(作为典型的商业应用程序)处理用户、公司和地址，我将有一个 User、一个 Company 和一个 Address 域类 - 可能会在某处弹出一个 UserManager、一个 CompanyManager 和一个 AddressManager 来处理这些事情.>

那么你能说出那些 UserManager、CompanyManager 和 AddressManager 是做什么的吗?不，因为管理器是一个非常通用的术语，适用于您可以对域对象执行的任何操作.

我读过的文章推荐使用非常具体的名称.如果它是一个 C++ 应用程序并且 UserManager 的工作是从堆中分配和释放用户，它不会管理用户，而是保护他们的生死.嗯，也许我们可以称之为 UserShepherd.

或者 UserManager 的工作可能是检查每个 User 对象的数据并以加密方式对数据进行签名.然后我们就有了一个 UserRecordsClerk.

既然这个想法一直困扰着我，我就尝试应用它.发现这个简单的想法非常困难.

我可以描述这些类的作用，并且(只要我不陷入快速和肮脏的编码)我编写的类完全一件事.我想念从描述到名称的一种名称目录，一种将概念映射到名称的词汇表.

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

• Factory - 创建其他对象(命名取自设计模式)
• Shepherd - Shepherd 处理对象的生命周期、它们的创建和关闭
• 同步器 - 在两个或多个对象(或对象层次结构)之间复制数据

• Nanny - 帮助对象在创建后达到可用"状态 - 例如通过连接到其他对象

• 等等

那么，你是如何处理这个问题的?你有固定的词汇吗?你是在飞快地发明新名字还是考虑给不那么重要或错误的东西命名?

P.S.:我也对讨论该问题的文章和博客的链接感兴趣.首先，这是让我思考的原始文章:命名 Java 类没有经理"

<小时>

更新:答案摘要

这是我在此期间从这个问题中学到的一点总结.

• 尽量不要创造新的比喻(保姆)
• 看看其他框架是做什么的

有关此主题的更多文章/书籍:

• 你觉得自己在加什么名字/定期上课?
• 命名类的最佳方法是什么?
• 书籍:设计模式:可重用面向对象软件的元素(精装)
• 图书:企业应用程序架构模式(精装本)
• 书籍:实施模式(平装本)

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

• 协调员
• 生成器
• 作家
• 读者
• 处理程序
• 容器
• 协议
• 目标
• 转换器
• 控制器
• 查看
• 工厂
• 实体
• 桶

还有一个很好的道路提示:

<块引用>

不要让命名瘫痪.是的，名称非常重要，但它们的重要性不足以浪费大量时间.如果你不能在 10 分钟内想出一个好名字，那就继续吧.

解决方案

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

似乎Helper、Manager 和Util 是您为协调不包含状态的类而附加的不可避免的名词，并且通常是过程性和静止的.另一种方法是Coordinator.

你可以得到带有名字的特别紫色的散文，比如Minder、Overseer、Supervisor、Administrator 和 Master，但正如我所说，我更喜欢将它保留为您习惯的框架名称.

<小时>

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

• 构建器
• 编写器
• 阅读器
• Handler
• 容器

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.

So can you tell what those UserManager, CompanyManager and AddressManager do? No, because Manager is a very very generic term that fits to anything you can do with your domain objects.

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. Hmm, maybe we could call this a UserShepherd.

Or maybe the UserManager's job is to examine each User object's data and sign the data cryptographically. Then we'd have a 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, e.g. a factory)

• Factory - Creates other objects (naming taken from the design pattern)
• 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?

P.S.: I'm also interested in links to articles and blogs discussing the issue. As a start, here is the original article that got me thinking about it: Naming Java Classes without a 'Manager'

---

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.

解决方案

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.

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. An alternative is 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.

---

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

• Builder
• Writer
• Reader
• Handler
• Container

这篇关于命名类 - 如何避免将所有内容都称为“&lt;WhatEver&gt;Manager"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！