PBL 中包的大小无限增长是合理的,因为功能越添越多,而 PBF 中包太大(包里 class 太多)表示这块需要重构(划分子包)。
如要知道更多好处,可以查看这篇博文:Package by features, not layers,当然,我们大谷歌也有相应的 Sample:todo-mvp,其结构如下所示,很值得学习。
com
└── example
└── android
└── architecture
└── blueprints
└── todoapp
├── BasePresenter.java
├── BaseView.java
├── addedittask
│ ├── AddEditTaskActivity.java
│ ├── AddEditTaskContract.java
│ ├── AddEditTaskFragment.java
│ └── AddEditTaskPresenter.java
├── data
│ ├── Task.java
│ └── source
│ ├── TasksDataSource.java
│ ├── TasksRepository.java
│ ├── local
│ │ ├── TasksDbHelper.java
│ │ ├── TasksLocalDataSource.java
│ │ └── TasksPersistenceContract.java
│ └── remote
│ └── TasksRemoteDataSource.java
├── statistics
│ ├── StatisticsActivity.java
│ ├── StatisticsContract.java
│ ├── StatisticsFragment.java
│ └── StatisticsPresenter.java
├── taskdetail
│ ├── TaskDetailActivity.java
│ ├── TaskDetailContract.java
│ ├── TaskDetailFragment.java
│ └── TaskDetailPresenter.java
├── tasks
│ ├── ScrollChildSwipeRefreshLayout.java
│ ├── TasksActivity.java
│ ├── TasksContract.java
│ ├── TasksFilterType.java
│ ├── TasksFragment.java
│ └── TasksPresenter.java
└── util
├── ActivityUtils.java
├── EspressoIdlingResource.java
└── SimpleCountingIdlingResource.java
参考以上的代码结构,按功能分包具体可以这样做:
com
└── domain
└── app
├── App.java 定义 Application 类
├── Config.java 定义配置数据(常量)
├── base 基础组件
├── custom_view 自定义视图
├── data 数据处理
│ ├── DataManager.java 数据管理器,
│ ├── local 来源于本地的数据,比如 SP,Database,File
│ ├── model 定义 model(数据结构以及 getter/setter、compareTo、equals 等等,不含复杂操作)
│ └── remote 来源于远端的数据
├── feature 功能
│ ├── feature0 功能 0
│ │ ├── feature0Activity.java
│ │ ├── feature0Fragment.java
│ │ ├── xxAdapter.java
│ │ └── … 其他 class
│ └── …其他功能
├── injection 依赖注入
├── util 工具类
└── widget 小部件
3.2 类名
类名都以 UpperCamelCase
风格编写。
类名通常是名词或名词短语,接口名称有时可能是形容词或形容词短语。现在还没有特定的规则或行之有效的约定来命名注解类型。
名词,采用大驼峰命名法,尽量避免缩写,除非该缩写是众所周知的, 比如 HTML、URL,如果类名称中包含单词缩写,则单词缩写的每个字母均应大写。
类 | 描述 | 例如 |
---|---|---|
Activity 类 |
Activity 为后缀标识 |
欢迎页面类 WelcomeActivity |
Adapter 类 |
Adapter 为后缀标识 |
新闻详情适配器 NewsDetailAdapter |
解析类 | Parser 为后缀标识 |
首页解析类 HomePosterParser |
工具方法类 | Utils 或 Manager 为后缀标识 |
线程池管理类:ThreadPoolManager |
日志工具类:LogUtils
(Logger
也可)
打印工具类:PrinterUtils
|
| 数据库类 | 以 DBHelper
后缀标识 | 新闻数据库:NewsDBHelper
|
| Service
类 | 以 Service
为后缀标识 | 时间服务 TimeService
|
| BroadcastReceiver
类 | 以 Receiver
为后缀标识 | 推送接收 JPushReceiver
|
| ContentProvider
类 | 以 Provider
为后缀标识 | ShareProvider
|
| 自定义的共享基础类 | 以 Base
开头 | BaseActivity
, BaseFragment
|
测试类的命名以它要测试的类的名称开始,以 Test 结束。例如:HashTest
或 HashIntegrationTest
。
接口(interface):命名规则与类一样采用大驼峰命名法,多以 able 或 ible 结尾,如 interface Runnable
、interface Accessible
。
注意:如果项目采用 MVP,所有 Model、View、Presenter 的接口都以 I 为前缀,不加后缀,其他的接口采用上述命名规则。
3.3 方法名
方法名都以 lowerCamelCase
风格编写。
方法名通常是动词或动词短语。
方法 | 说明 |
---|---|
initXX() |
初始化相关方法,使用 init 为前缀标识,如初始化布局 initView() |
isXX() , checkXX() |
方法返回值为 boolean 型的请使用 is/check 为前缀标识 |
getXX() |
返回某个值的方法,使用 get 为前缀标识 |
setXX() |
设置某个属性值 |
handleXX() , processXX() |
对数据进行处理的方法 |
displayXX() , showXX() |
弹出提示框和提示信息,使用 display/show 为前缀标识 |
updateXX() |
更新数据 |
saveXX() , insertXX() |
保存或插入数据 |
resetXX() |
重置数据 |
clearXX() |
清除数据 |
removeXX() , deleteXX() |
移除数据或者视图等,如 removeView() |
drawXX() |
绘制数据或效果相关的,使用 draw 前缀标识 |
3.4 常量名
常量名命名模式为 CONSTANT_CASE
,全部字母大写,用下划线分隔单词。那到底什么算是一个常量?
每个常量都是一个 static final
字段,但不是所有 static final
字段都是常量。在决定一个字段是否是一个常量时,得考虑它是否真的感觉像是一个常量。例如,如果观测任何一个该实例的状态是可变的,则它几乎肯定不会是一个常量。只是永远不打算改变的对象一般是不够的,它要真的一直不变才能将它示为常量。
// Constants
static final int NUMBER = 5;
static final ImmutableListNAMES = ImmutableList.of(“Ed”, “Ann”);
static final Joiner COMMA_JOINER = Joiner.on(’,’); // because Joiner is immutable
static fin