2
您是否厌倦了旧的经理和处理程序类？全部使用...物件，...定义，Doodad，...实体，... Gizmo或...对象后缀？我当然是，并且做到了。通用应用程序构建块的类名称
所以在这里我想收集有用的Classnames。
我认为this文章最好的描述是：
不要使用“管理器”或“助手”或 其他空字的类型名称。
如果需要的 “助手”添加“经理人”一类的名称，类型是 是命名不足或不当 设计。可能后者。 类型应该管理和帮助自己。
所以这里头数：
- 邮箱
- 把手消息
- 使者
- 供应通知或其他种类的消息 的
- 仪表板
- 所提供的数据
- 渲染
- agregates /构建数据
我真的不知道放在哪里了 “Widget”是好是坏？ 还有我目前正在寻找名字类，：
- 身份验证与服务器（蹦床？）
- 数据跟踪更改
- 持有和跟踪文件
- 管理Dialoges
一个常用于跟踪文档的类需要能够做到这样的事情：onBeforeDocumentChanged做些什么。该类可能会使用一个集合，但不是一个集合（至少不是纯集合），因为它需要包含buisnesslogic。 经理是一个不好的后缀，因为如果你从那开始，你将有很多经理。 DocumentManager，ConnectionManager，DataManager我可以这样想。为什么你不好问？那么现在几乎每个班级都是一个班级，那么这不是管理者的一部分吗？ “类型应该管理和帮助自己” – 2009-06-23 14:48:43