这是一个系列,我们将其命名为工具箱,如果你还没有看之前的文章:
概览
Android应用需要有良好的包结构定义,这会使得你的代码更易被阅读,通常来说,恰当的命名规范能够保证你的代码更易被维护和整洁。
命名规范
针对Java代码
下列规则对于Java代码很重要:
变量 规范:所有变量都必须为小写字母开始,且驼峰式。例如:incomeTaxRate
常量 规范:所以常量都必须为大写字母。例如:DAYS_IN_WEEK
方法 规范:所有变量都必须为小写字母开始,且驼峰式。例如:convertToEuroDollars
方法参数 规范:所有参数必须小写字母开始,且驼峰式。例如:depositAmount
针对Android类
Android类的命名规则有其自己的一套规范,以使得其类作用更加明显。比如所有的activity都会以activity结尾。
Activity 规范:CreateTodoItemActivity。继承于:AppCompatActivity,Activity。
List Adapter 规范:TodoItemsAdapter。继承于:BaseAdapter,ArrayAdapter。
数据库帮助类 规范:TodoItemsDbHelper。继承于:SQLiteOpenHelper。
网络客户端 规范:TodoItemsClient。
Fragment 规范:TodoItemDetailFragment。继承于:Fragment。
Service 规范:FetchTodoItemService。继承于:Service, IntentService。
你在命名Android类之前,最好思考下,目标是任何Android类都需要特殊定义的前缀。
包结构定义
包结构的定义分歧很大,但是基本维持在两种模式:
按照种类分类
其含义为:将app的每个特性都应该区分开。
com.example.myapp.activities – 包含所有的activity类
com.example.myapp.adapters – 包含所有的adapter类
com.example.myapp.models – 包含所有的数据模型
com.example.myapp.network – 包含所有的网络代码
com.example.myapp.fragments – 包含所有的碎片
com.example.myapp.utils – 包含所有的帮助类
com.example.myapp.interfaces – 包含所有的接口
按照app应用特性区分
com.example.myapp.service.* – 包含所有的后台服务类
com.example.myapp.ui.* – 包含所有的UI相关类
com.example.myapp.ui.mainscreen – 包含所有的主屏幕相关类
com.example.myapp.ui.detailsscreen – 包含所有的其他屏幕相关类
这一定义,可以让你将DetailsActivity, DetailsFragment, DetailsListAdapter, DetailsItemModel放在一个包中。
DetailsListAdapter和DetailsItemModel类可以将其属性定义为protected,这样其他包中的代码需要通过get/set访问属性。
这使得创建实例更加简单和直观,因为对象在包外是不可改变的。
结论
这两种模式都可以,取决于哪一个更加适合你的项目,然而,通常在Java代码中,第二种模式即按照特性划分更加有利和被推荐。