2015年11月19日 第一版
链接：http://qiita.com/KeithYokoma/items/ee21fec6a3ebb5d1e9a8
原作者：KeithYokoma
译者：dssunxun
类名一般上多使用名词，方法名一般多用动词和助动词，这是因为类名要抽象出拥有某种职责的某物，
所以多使用名词。
另一方面，声明接口时，我们一般使用形容词来作为接口的名称（例如：Iterable、Closeable等）。
通过使用形容词，可以较好的注明类所拥有的特性
业务逻辑类
即一般所谓的Model层，该层有着各种不同功能的类。
一般性的，给该层的类起名都是Model或是Manager这样的名字，而随着业务的增多，该层也会变的越来越肥大。
实际上在Model层中也有各种各样的层，通过给它们起好名字明确它们的功能，然后组合起来建立起业务逻辑
操作DataSource的层
大致上就是拥有某些I/O的基础功能(增删查改、request等)的类，比如说，拥有操作DB逻辑的类、拥有通过
HTTP通信获取Response的类
| 名称 | 补充说明 | 例 |
|---|---|---|
| Client | 类似HttpClient这样的，在有Server-Client的含义的情况下使用 | TwitterApiClient, QiitaApiClient |
| Gateway | 作为访问API时的网关时使用 | TwitterTimelineGateway, QiitaAccountGateway |
| Store，Storage、Registry | 访问数据库，在磁盘进行数据持久化时使用 | FavoriteSettingStore, DataStorage, ConfigRegistry |
| Cache | 缓存时使用 | TimelineCache |
| Log | 日志。或是存储操作历史记录的路径 | UsageLog |
| History | 存储历史记录的路径 | UsageHistory |
| Configuration, Preference, Setting | 存储设定数据的路径 | TimelineConfiguration |
有必要的话，可将I/O的基本功能各自分开实现（可提供一个统一管理的接口或是一开始就创建个统一管理的类来操作）
| 名称 | 补充说明 | 例 |
|---|---|---|
| Logger | 执行日志操作 | UsageLogger |
| Cleaner, Sweeper | 清除数据时使用 | CacheCleaner, CacheSweeper |
加工数据的层
| 名称 | 补充说明 | 例 |
|---|---|---|
| Filter | 筛选数据时使用 | TimelineFilter |
| Extractor | 从某个数据中抽出其他数据 | MessageExtractor |
| Formatter | 格式化某个数据输出为其他数据 | MessageFormatter |
| Collector | 收集数据 | AnalyticsDataCollector |
拉取DataSource的层
取得数据、存储为Cache、然后再将其返回给Controller和Presenter层的层。该层的Model从使用者看来，无需在意获得
的数据是否是从Cache而来。
| 名称 | 补充说明 | 例 |
|---|---|---|
| Provider | 将上面提到过的DB、http通信、Cache等封装化后的上位层。或是Android中的ContentProvider | TwitterTimelineProvider |
| Manager | 管理数据 | AccountManager |
| Loader | 读取数据 | TimelineLoader |
| Logger | 写日志、或是提供访问Log的抽象层 | RecentUsageLogger |
| Configurator | 存储设定的默认值、将某种数据自动的保存到设定 | FirstSettingConfigurator |
| Migrator | 处理当版本升级等数据结构发生变化时的逻辑 | UserDataMigrator |
进行异步处理的层
| 名称 | 补充说明 | 例 |
|---|---|---|
| Job, Task, Runnable, Executable | 统一处理异步操作 | UploadJob, MigrationTask |
| Runner, Executor, Worker | 执行被给予的Job和Task | UploadJobRunner, MigrationTaskExecutor |
| Aware | 拥有同步操作相关的某些Context，表示在其管理下的接口（Spring Framework有使用） | ApplicationContextAware |
集成访问FrameWork的层
基于Facade模式、提供通向其他的Framework和SubSystem接口的层
| 名称 | 补充说明 | 例 |
|---|---|---|
| Facade | 实现Facade模式 | BoundServiceFacade |
| Service | 将兼容性的实现给封装化，并实现对各种功能的访问的层 | ApplicationControllerService |
| Resolver | 根据用户环境进行Routing处理的层 | ContentResolver |
操作View的类
即一般上的Controller层，根据所用的Framework有所不同，大致上一般会命名为如下。
严格来讲，与Presenter有些许的不同，在此将其包含进去
| 名称 | 补充说明 |
|---|---|
| Activity | Android中使用 |
| Fragment | Android中使用 |
| ViewController | iOS中使用 |
| Controller | MVC中的Controller |
| Screen.Presenter | MVP中的Presenter。Mortar中使用 |
| Window |
包含UI上的动作的类
抽象特定的操作，并将该操作想执行的处理综合起来的类。也可作为接口名称使用
| 名称 | 补充说明 | 例 |
|---|---|---|
| Action | 表示操作 | SubmitAction, CancelAction |
| Dispatcher, Handler | 接受操作执行处理 | SubmitActionDispatcher, UserActionHandler |
| Listener, Watcher | 监视操作。Observer模式的实现名 | ClickListener, TextEditWatcher |
总结
因语言和框架带来的作法和规则的不同，并没有什么一个最好的方法。设计和重构时，在想好了
如何分层后，如何命名也非常重要。在上面我列举了很多，但是直接用有名的设计模式和框架中用到的名字
有可能也比较好。所以尽可能的清楚地起个能把一个类的作用给表现出来的名字吧