较好的类名命名规则

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

总结

因语言和框架带来的作法和规则的不同，并没有什么一个最好的方法。设计和重构时，在想好了

如何分层后，如何命名也非常重要。在上面我列举了很多，但是直接用有名的设计模式和框架中用到的名字

有可能也比较好。所以尽可能的清楚地起个能把一个类的作用给表现出来的名字吧