类命名混乱
我经常纠结如何命名一个类。 并不是因为该类的用途不清楚，而是因为像 xxx***Controller***、xxx***Manager***、xxx***Info***、xxx***Helper*** 这样的名称、 xxx***Util*** 等我随处可见。
如果我有一个通过 HTTP 上传一些内容的类，我倾向于将其命名为 HttpUploader 或类似的名称。 我见过很多类似的类被命名为 HttpUploadManager、HttpTransmissionController、HttpUploadHelper 等的实例。
我对何时使用 Controller、Manager、Info 等感到有点困惑。 有没有任何文章或书籍可以帮助我成为更好的类命名者？
PS：另外，像 HttpSender 这样的名称听起来不错与 HttpTransmissionController 或 HttpDispatchManager 相比，相当贫乏：P
I often struggle with deciding how to name a class. Not so much because the class's purpose is unclear, but because of names like xxx***Controller***, xxx***Manager***, xxx***Info***, xxx***Helper***, xxx***Util*** etc that I see everywhere.
If I have a class that uploads some stuff over HTTP, I tend to name it HttpUploader or something on those lines. I have seen many instances where a similar class being named HttpUploadManager, HttpTransmissionController, HttpUploadHelper and so on.
I am sort of confused as to when to use Controller, Manager, Info etc. Is there any article or book that can help me become a better namer of classes?
PS: Also, a name like HttpSender sounds pretty anemic when compared to HttpTransmissionController or HttpDispatchManager :P
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
命名很难，所以不用担心你会遇到困难，因为我们都一样。 相信我，事情永远不会变得更容易！
就我个人而言，对于整个 Controller/Manager/Helper/Util/Whatever 后缀事物，我倾向于使用以下规则：如果它是一个约定（例如，对于 ASP.NET MVC，它是控制器类名称以“Controller”结尾的约定），则使用后缀，否则请尽力避免它。 我宁愿有一个名为
HttpUploader的类，而不是HttpUploadManager。关于命名最重要的事情是类应该按照它所说的去做。 如果它是一个使用 HTTP 上传内容的类，那么 HttpUploader 会准确地描述它。 使用像
HttpUploadManager这样的奇特名称并不能告诉我它的作用。 它自己上传东西吗？ 它可以管理多个内容的上传吗？ 我喜欢让事情尽可能简单，同时描述类/方法/任何内容的目的。我发现的一个很好的指导原则是，如果你真的很难命名某些东西，就像你花了很长时间思考但你仍然无法将它的作用提炼成一个合理的名称，那么你可能需要重构你正在尝试的任何东西命名为更小、更具体的组件。
Naming is hard, so don't worry that you struggle, because we all do. And trust me, it never gets any easier!
Personally with the whole Controller/Manager/Helper/Util/Whatever suffix thing I tend to use the rule that if it's a convention (e.g. for an ASP.NET MVC it's convention that the controller class name ends in "Controller") then use the suffix, otherwise try like hell to avoid it. I'd much rather have a class called
HttpUploaderthanHttpUploadManager.The most important thing about naming, is that the class should do what it says. If it is a class that uploads something using HTTP then
HttpUploaderdescribes it exactly. Using a fancy name likeHttpUploadManagerdoesn't tell me what it does. Does it upload the thing itself? Does it manage the upload of multiple things? I like to keep things as simple as possible, while describing the purpose of the class/method/whatever.A good guideline I find is that if you're really struggling to name something, like you've spend ages thinking and you still can't distill what it does into a reasonable name, then you probably need to refactor whatever you're trying to name into smaller, more specific components.
如果您在选择名称时遇到困难，可以咨询 ClassNamer.org。
If you are having difficulty selecting a name, you could consult ClassNamer.org.
关于 SO 的流行观点似乎是避免使用 Manager、Info、Helper 或 Util 等后缀。
请参阅：Smelly 类名称 和 需要重构的类名。
The popular opinion on SO seems to be to avoid the use of suffixes like Manager, Info, Helper, or Util.
See: Smelly Class Names and Class names that need refactoring.
您也可以尝试查看更具描述性（彩色？）后缀的列表： ManagerManager。
通常的建议（根据类的作用来命名类）的问题在于，类所做的许多事情在现实世界中都没有很好的对应项，因此我们的传统词汇可能不太匹配。 例如，HttpUploader 可能与另一个帮助上传、进行一些协调或（我敢说吗？）管理上传的类配对。 这种中间人协调在软件中很常见，但描述它的词语都非常模糊，以至于招致蔑视。
You could try looking at a list of more descriptive (colorful?) suffixes too: ManagerManager.
The problem with the usual advice (name the class for what it does) is that many of the things a class does have no good real-world equivalent, and so our traditional vocabulary may not match well. For example, an HttpUploader may be paired with another class that helps with the uploading, doing some coordinating, or (dare I say it?) manages the uploading. This sort of middleman coordination is common in software, but the words to describe it are all so vague that they invite scorn.
Clean Code 一书有关于变量的完整章节名称。 好东西。
The book Clean Code has a full chapter on variable names. Good stuff.