uri*_*ium 19 language-agnostic oop design-patterns naming-conventions
我正在阅读书清洁代码http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
作者提到您应该在类的名称中避免使用管理器,处理器,数据或信息等单词.我到处都用过这些.什么是更好的名字？我有一个负责启动和停止连接的类.所以我把它命名为ConnectionManager.
myA*_*ces 24
等待!
本书的重点是,类名中的管理器意味着该类不止一件事.Robert C. Martin在本节中提到单一责任原则!
这不是关于名称,关于通常这样命名的类.更改名称不会减少课程的责任!
Cod*_*ray 12
我的猜测是这本书说明了这一点,因为它试图鼓励你为你的班级选择一个更具描述性的名字.这里没有"命名惯例"; 这就是你首先遇到的问题.任何通用命名约定都无法考虑特定类并为其选择最佳名称.表达性比遵循命名约定更重要.将类称为"管理器"或"处理器"并没有说明它以及它对第一次阅读代码的人所做的事情.
如果你真的想不出更好的东西,那么命名一个类就没有什么本质上的错误ConnectionManager.但我至少在它管理的集合类型之后命名它.或者也许它如何管理这些集合.或者为什么它管理这些集合.
还要考虑遵循"一刀切"的规则很少帮助任何人编写更好的代码(至少,在"更易理解"或"更具表现力"的意义上并不是更好.)我倾向于后缀所有我的名字本地包装类用Manager.例如,我可能会类调用DwmManager,或者VisualStylesManager,在这种非常特殊的情况下,它确实意味着什么给我.如果我看到一个名为类Manager在我的代码基础,我知道它包装了一堆密切相关功能.您必须根据具体情况做出决定,了解您最终要完成的任务.
如果您阅读Code Complete并错过了编写清晰且易于理解(因此可维护)的代码的部分,您可能错过了这一点.
在ConnectionManager类的示例中,类可能更多地表示设计缺陷,这需要"坏"名称.除了执行可以在名为MyDatabaseConnection的单例子类中轻松完成的操作之外,该类是否还在执行某些操作？
Jam*_*.Xu -5
不要太在意这个名字，不要太在意它，除非你或某人真的不喜欢它。