13
命名类-如何避免将所有内容都称为“ <WhatEver> Manager”？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 很久以前，我读过一篇文章（我相信是博客文章），这使我走在命名对象的“正确”轨道上：在程序中命名事物时要非常谨慎。 例如，如果我的应用程序（作为典型的业务应用程序）正在处理用户，公司和地址，则我将具有User，a Company和Address域类-可能会弹出a UserManager，a CompanyManager和a AddressManager来处理这些问题。 所以，你可以告诉那些UserManager，CompanyManager和AddressManager做什么？不可以，因为Manager是一个非常通用的术语，适用于您可以使用域对象执行的所有操作。 我阅读的文章建议使用非常具体的名称。如果它是C ++应用程序，并且UserManager的工作是分配用户并将其从堆中释放出来，那么它将不会管理用户，而是保护用户的生死。嗯，也许我们可以将其称为UserShepherd。 或者，也许UserManager的工作是检查每个User对象的数据并用密码对数据签名。然后我们会有一个UserRecordsClerk。 现在，这个想法一直困扰着我，我尝试应用它。并且很难找到这个简单的想法。 我可以描述这些类的作用，并且（只要我不会陷入快速而肮脏的编码中）我编写的类就可以做一件事。从描述到名称，我想念的是一种名称目录，这是一个将概念映射到名称的词汇表。 最终，我想在脑海中想起一个模式目录（通常，设计模式很容易提供对象名称，例如工厂） 工厂-创建其他对象（取自设计模式的命名） 牧羊人-牧羊人处理对象的生命周期，对象的创建和关闭 同步器-在两个或多个对象（或对象层次结构）之间复制数据 保姆-帮助对象在创建后达到“可用”状态-例如，通过连接到其他对象 等等等 那么，您如何处理该问题？您是否有固定的词汇表，是否在动态地发明新名称，或者您认为命名不那么重要或错误？ PS：我也对讨论该问题的文章和博客链接感兴趣。首先，这是让我思考的原始文章：不带“ Manager”命名Java类 更新：答案摘要 这是我同时从这个问题中学到的一些小知识。 尽量不要创建新的隐喻（保姆） 看看其他框架做什么 有关此主题的其他文章/书籍： 您会发现自己经常定期参加哪些课程？ 命名类的最佳方法是什么？ 图书：设计模式：可重用的面向对象软件的元素（精装本） 书籍：企业应用程序架构的模式（精装） 书籍：实施模式（平装本） 还有我从答案中（主观地！）收集的名称前缀/后缀的当前列表： 协调员 建造者 作家 读者 处理程序 容器 协议 目标 转换器 控制者 视图 厂 实体 桶 道路上的一个好提示： 不要让命名麻痹。是的，名称很重要，但它们的重要性还不足以浪费大量时间。如果您不能在10分钟内想到一个好名字，那就继续吧。