相关疑难解决方法(0)

很久以前我读过一篇文章(我相信一篇博客文章),它让我在命名对象的"正确"轨道上:非常谨慎地命名程序中的东西.

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

所以,你可以告诉那些UserManager,CompanyManager和AddressManager做什么？不,因为Manager是一个非常通用的术语,适用于您可以对域对象执行的任何操作.

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

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

现在这个想法一直困扰着我,我尝试应用它.并且发现这个简单的想法非常难.

我可以描述这些类的功能和(只要我不进入快速和脏编码)我写的类只做一件事.我想念从名称到名称的是一种名称目录,一种将概念映射到名称的词汇表.

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

• Factory - 创建其他对象(从设计模式中获取命名)
• 牧羊人 - 牧羊人处理物体的生命,它们的创建和关闭
• 同步器 - 在两个或多个对象(或对象层次结构)之间复制数据

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

• 等等

那么,你如何处理这个问题呢？你有一个固定的词汇表,你是否动态发明新的名字,或者你认为命名的东西不是那么重要或错误？

PS:我也对链接​​到讨论这个问题的文章和博客感兴趣.首先,这是让我思考它的原始文章:在没有"经理"的情况下命名Java类

更新:答案摘要

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

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

关于这个主题的进一步文章/书籍:

• 你发现自己经常在课前做什么名字？
• 命名类的最佳方法是什么？
• 书:设计模式:可重用面向对象软件的元素(精装)
• 书:企业应用程序架构模式(精装)
• 书:实施模式(平装)

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

• 协调员
• 生成器
• 作家
• 读者
• 处理器
• 容器
• 协议
• 目标 …

在课程结束时,您发现自己经常使用哪些名词？

例如,我习惯坚持Info传递信息的类,但没有做很多事情:

• ImportInfo
• SiteInfo

或者用于协调课程:

• UserManager
• SecurityManager

我最终Builder经常使用字符串相关的类,即使它几乎没有任何建筑:

• TemplateBuilder
• HtmlBuilder

当然还有永恒的Helper/Utility类:

• PhraseHelper
• NumberUtility
• FileHelper

你有什么好处,我的意思是你经常用来表示班级主要角色的简洁和描述性的名词或单词吗？

这个问题针对.NET世界,但可以扩展到Java,C++,Python等.

您对如何组织和命名实用程序类有任何意见吗？

每当我遇到一些代码复制时,可能只是几个代码行,我将它们移动到实用程序类.

过了一会儿,我往往会得到很多的小静态类,通常只有一个方法,我usualy放在一个utility是它和类臃肿的命名空间.

例子:

ParseCommaSeparatedIntegersFromString( string )
CreateCommaSeparatedStringFromIntegers( int[] )
CleanHtmlTags( string )
GetListOfIdsFromCollectionOfX( CollectionX )
CompressByteData( byte[] )

通常,命名约定会告诉您将类命名为名词.我经常最终得到很多类HtmlHelper,CompressHelper但它们的信息量不大.我也尝试过非常具体的HtmlTagCleaner,通常每个实用程序方法最终会有一个类.

您对如何命名和分组这些辅助方法有任何想法吗？

我正在阅读书清洁代码http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

作者提到您应该在类的名称中避免使用管理器,处理器,数据或信息等单词.我到处都用过这些.什么是更好的名字？我有一个负责启动和停止连接的类.所以我把它命名为ConnectionManager.

我发现了一些像这样的文章,这些文章表明某些词语永远不应该被用作类名的一部分.当一个类在名称中包含其中一个单词时,表示代码应该被重构或重新设计.

例:

经理

理由:由于几乎所有课程都"管理"某些内容并且"经理"的含义非常广泛,人们可以将很多职责交给"经理"课程,同时仍然能够宣称课程"只有一件事".因此,使用"Manager"命名一个类并没有说明该类实​​际上做了什么.前面提到的文章"命名没有'经理'的Java类",显示了这一点:

例如,使用名为"UrlManager"的类 - 您无法判断它是否汇集URL,操纵URL或审核它们的使用.所有的名字告诉你,这不是一个URL,但它确实与它们一起工作.另一方面,名称"UrlBuilder"可以更好地描述该类的功能.

另一个例子:

帮手

原因:像"ThreadHelper"这样的类名使人们想知道为什么需要它以及为什么它不能只是"Thread"类的一部分.它实际上是适配器还是装饰器？如果是这样,那就这样命名.班级"线程"已经承担了太多的责任吗？如果是这样,重构并为新类赋予有意义的名称."助手"没有说明它正在做什么或它如何帮助.

类名中的其他单词是否表示需要重构或重新设计,应该避免？为什么？

编辑:我认为这些词语经常被使用

• 它们通常具有广泛的含义
• 它们几乎适合所有环境
• 他们阻止设计师考虑更好的设计或名称
• 人们相信使用它们是可以的

清洁代码一书列出了更多,但没有给出任何理由:

避免使用类名称中的管理器,处理器,数据或信息等字样.

如果有人能为他们提供可能的理由,那就太棒了.

相关问题:

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

好的,所以你可以阅读关于标识符命名的指导原则,直到你脸色发青蓝......骆驼的情况下,pascal的情况下,让它们描述性......但它们无法帮助你真正选择给定的最佳名称应用领域.

最容易选择(恕我直言)是一个或两个单词的名词组:

• 报名表
• 雇员
• WidgetCollection

但并不是每个类都整齐地适合一个名词,所以我看到很多人通过在它们的末尾添加-er将动词变为名词:

• 客户经理
• RecordCounter
• ProcessRunner

我看到这个问题的最大问题是很多时候他们都很模糊......特别是经理.究竟是什么管理？

所以我的问题是你如何为一个班级选择一个好名字？"好",我的意思是内容丰富,毫不含糊.

我知道我知道.几乎每个现代IDE都内置了重构支持,您可以更改名称而不必睁眼,那么重点是什么？一个选择不当的名字会混淆和误导任何偶然发现它的人,直到它被重命名为止,这仍然是一个有效的问题.

有关

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