※ 引述《wong0101 (wong0101)》之铭言：
: 最近在碰android的source code,
: 发现很多class的命名都有相似之处,
: 例如: xxxManager, xxManagerService, Policy, Utilities..等
: 感觉这些class做的事情有一定的相似之处
: 例如:
: xxManagerService在整个android环境中只有一个实例(吗?)
: Utilities会放一些常用的static方法(吗?)
: 我想请教的是
: (1)上述举例的这些类别(xxxManager, xxManagerService, Policy, Utilities)
: 他们有什么样的共同特性呢?让我们能根据命名知道这个class的功用
: (2)另外还有什么样的命名方式是我上面没举例到的呢
: 先谢谢大家了~
这跟 java 的 Design Pattern 有关系
以数据库存取来说
就会分为三类 Entity, DAO, Service
命名规则则是
Entity = TableName
DAO = TableNameDAO
Service = TableNameService
而各自负责的工作分别是
Entity 为 Table 的实体资料物件
DAO 为存取资料的窗口
Service 则是做中间的逻辑判断, DAO 之间的交流以及其他各式处理
而你的 Controller 只要负责呼叫 Service 取得你要的资料即可
而由以上范例你可以发现
Service 就是负责主要的逻辑处理
不论是从网络捞资料还是从档案或数据库
都会在这边处理为一个物件后 回传给 Controller
再由 Controller 分配给某个 View 进行处理然后显示
再说得简单一点
其实就是一种让开发者之间可以更好的交流程式码的一种设计方法
所谓的交流最重要的就是 交接!!!!!!
至少你看名称就知道那个东西可能在做些什么
所以程式设计师有80%的时间在想名字要怎么取(!?)
但其实要遵守 Design Pattern 不靠自动化工具还满花时间的
有时候我自己也是 阿~ 隆吼哩啦~ 程式码随便丢
不过最后都会后悔为什么当初不照着做 然后认命慢慢搬
若要深入的了解这一方面
可以找找看主流的 java design pattern
除了我上面提到的数据库存取以外还有很多
例如 Builder, Null Object 等等
这方面如果公司有前辈带会学得比较快 观念也会比较清楚
像我都是自己慢慢 Google 学得就比慢 观念也很杂
至于要不要照着做就是看你自己了
毕竟很多 Design Pattern 主要还是针对维护方面
不论是减少 Debug 的难度还是加速 Debug 的速度
一开始难免会影响开发速度
但这种事情是先苦后甘啦
除非你 Coding 完就离职 然后对公司怀有恨意
不过最后悽惨的也是接手的人而不是公司就是了