命名类 - 如何避免调用所有的“< WhatEver>管理器”？ [英] Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?

问题描述

很久以前，我已经阅读了一篇文章（我相信一个博客条目），它使我对命名对象的正确轨迹：在程序中命名事情非常谨慎。

例如，如果我的应用程序（作为典型的商业应用程序）处理用户，公司和地址，我将有一个用户，一个公司和一个地址域类 - 可能位于某个 UserManager 一个 CompanyManager 和一个 AddressManager 将弹出来处理这些事情。

那么你可以告诉那些 UserManager ， CompanyManager 和 AddressManager 吗？不，因为管理器是一个非常通用的术语，适合您可以对域对象执行的任何操作。

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

或者也许 UserManager 的工作是检查每个User对象的数据，并以密码方式对数据进行签名。那么我们将有一个 UserRecordsClerk 。

现在，这个想法和我一起试图应用它。我可以用这个简单的想法找到这个简单的想法。

我可以描述什么是类，（只要我不会进入快速和脏的编码）写做完全一个的事情。我从这个描述中想念的名字是一种名称目录，一个将概念映射到名字的词汇。

最终我想要像我的头脑中的模式目录（通常设计模式很容易提供对象名称，例如一个工厂）

• 工厂 - 创建其他对象（从设计模式中命名）


• 牧羊人 - 牧羊人处理物体的生命周期，创建和关闭


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



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




• 等等。

那么，你怎么样处理这个问题？你有固定的词汇，你是否在飞行中发明新名字，还是考虑命名不重要或错误的东西？

PS：我也是感兴趣的链接，文章和博客讨论这个问题。作为一个开始，这是原始文章让我想到它：命名Java类没有经理

---

更新：答案摘要

以下是我在此期间从这个问题中学到的一点概要。

• 尽量不要创建新的隐喻（Nanny ）


• 查看其他框架的作用

有关此主题的其他文章/书籍：

• 你发现什么名字可以定期附加到课程中？


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


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


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


• 书籍：实施模式（平装本）

我从答案中收集了（主观！）的名称前缀/后缀列表：

• 协调员


• 生成器


• 作家


• 阅读器


• 处理者


• 容器


• 协议


• 目标


• 转换器


• 控制器


• 查看


• 工厂


• / li>
  
• Bucket

这是一条很好的提示：

不要吨得到命名瘫痪。是的，名字是非常重要的，但它们不够重要，浪费了大量的时间。如果你在10分钟内找不到好名字，请继续前进。

解决方案

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

似乎 Helper ，经理， Util 是不可避免的名词，用于协调不包含状态的类，一般程序和静态的。另一种方法是协调员。

你可以得到特别的紫色prosey与名称，并去像 Minder ，巡察，主管，管理，主但正如我所说，我更喜欢保持它像您使用的框架名称。

其他一些常见的后缀（如果这是正确的术语），你也在.NET框架中找到

• Builder


• 作家


• 阅读器


• 处理程序


• 容器

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, look for ideas in the Java and Android frameworks.

Seems Helper, Manager, Util is the unavoidable noun 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,Master but as I said I prefer keeping it like the framework names you're use to.

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

• Builder
• Writer
• Reader
• Handler
• Container

这篇关于命名类 - 如何避免调用所有的“< WhatEver>管理器”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！