0x1、引言
? 从六月开始,断断续续,算是把王争的《设计模式之美》看得差不多了,实战部分没来得及看,不过也是获益良多,思维方式上的一些变化。肚子里的墨水不多,不知道如何描述这种感觉,说两个实际的应用场景,读者自行意会哈,顺便带出总结思维导图~
日常开发应用示例一
拿到新的业务需求,不再是直接无脑拆分输出排期,复制粘贴改改代码,而是考虑更多:后续可能有哪些扩展、重复业务能否抽象复用等。举两个例子:
1、App里有不同的角色:二级代理、二级负责人、三级代理、三级负责人,然后一个列表页,不同的角色有不同的交互
如果是你用代码实现,你会怎么做?以前的我可能会这样做,把所有逻辑业务都塞到Fragment,一堆if-else
class UserInfoFragment: Fragment() {
// 加载Fragment
fun loading() {
if(isLeader) {
if (isSecond) {
// 二级负责人
} else {
// 三级负责人
}
} else {
if (isSecond) {
// 二级代理
} else {
// 三级代理
}
}
}
// 添加客户
fun addCustomer() {
if(isLeader) {
if (isSecond) {
// 二级负责人
} else {
// 三级负责人
}
} else {
if (isSecond) {
// 二级代理
} else {
// 三级代理
}
}
}
// 还有下面这些,也是如法炮制
// 搜索
// 选择代理项目
// 筛选
// 排序
// tab切换
}
复制代码
写if-else写到想哭,如果再来一类角色,又得套一层if-else,改动量巨大,每个方法都要改。
你可能会说,可以简化判断,定义一个常量属性/枚举来标记一种角色,开头走下判断条件,区分出角色,就不用每次都if-else了:
class UserInfoFragment: Fragment() {
var role = 0 // 1二级代理人、2二级负责人、3三级代理、4三级负责人
fun init() {
if(isLeader) {
if (isSecond) {
role = 2
} else {
role = 4
}
} else {
if (isSecond) {
role = 1
} else {
role = 3
}
}
}
// 加载Fragment
fun loading() {
when(role) {
1 -> 二级代理
2 -> 二级负责人
3 -> 三级代理
4 -> 三级负责人
}
}
复制代码
实际上,还是逃避不了判断,当角色发生改变,依旧要动很多代码,怎么写才能保持可扩展性呢?
抽象 + 多态 + 策略模式
可以把 业务逻辑抽象成一个对象,不同的角色进入这个页面,尽管表现不同,但是执行的业务逻辑是一样的,抽象出一个行为接口:
interface IOperate {
fun loading(container: Int)
fun addCustomer()
fun search(select: SelectItem? = null)
fun selectAgentProject(select: SelectItem? = null)
fun filter(height: Int, y: Int, select: SelectItem? = null, after: (() -> Unit)? = null)
fun order(height: Int, y: Int, after: (() -> Unit)? = null)
fun switchTap(pos: Int)
}
复制代码
接着定义一个 抽象角色类 来实现这个接口,原则是这样的:
- 不同角色,相同的逻辑在此重写,相同包括全部相同和部分相同。部分相同指的是部分代码逻辑相同,比如埋点,执行这个逻辑表现不同,但埋点是相同的。子类重写方法,调下super.xxx()复用相同代码,然后重写不同逻辑。
- 完全不同的逻辑,就不在父类中实现,而是交给具体的子类实现
abstract class Role(protected var mFragment: BaseFragment) : IOperate {
abstract var type: String // 描述字段,便于区分而已,没用
//...
override fun addCustomer() {
if (ClickFastUtils.isFastClick()) return
mFragment.go(AddCustomerFragment::class.java)
umAddClick.um(mFragment.context)
}
override fun filter(height: Int, y: Int, select: SelectItem?, after: (() -> Unit)?) {
umScreenClick.um(mFragment.context)
}
//...
}
复制代码
然后是 具体角色类,示例如下:
class SecondAgentRole(fg: BaseFragment) : Role(fg) {
override var type = "二级代理/经纪人"
override fun loading(container: Int) {
mFragment.childReplace(SecondAgentListFragment.newInstance(), container)
}
override fun filter(height: Int, y: Int, select: SelectItem?, after: (() -> Unit)?) {
super.filter(height, y, select, after)
if (select == null) {
shortToast("您当前不在任何代理项目中挂职,无法查看项目客户!")
return
}
after?.invoker()
//...其他逻辑
}
}
复制代码
接着就到Fragment了,因为 具体逻辑都分化到对应的角色 里了,所以它非常简单:
class CustomerFragment : BaseFragment() {
override fun initData(bundle: Bundle?) {
diffRole()?.loading(R.id.fly_content) // 区分用户角色并加载对应Fragment
}
// 区分用户角色
private fun diffRole(): Role? = when {
isLeader && isSecond -> SecondPrincipalRole(this)
isLeader && !isSecond -> ThirdPrincipalRole(this)
!isLeader && isSecond -> SecondAgentRole(this)
!isLeader && !isSecond -> ThirdPrincipalRole(this)
else -> null
}
}
复制代码
啧啧额,此时发生角色更改,改动的内容就非常小了:
- 修改判断逻辑 → 只在diffRole()方法中发生改动
- 增加角色 → 继承Role写一个角色子类,修改diffRole()方法
- 删除角色 → 直接把角色子类干掉,修改diffRole()方法
妙啊,当时硬是要吹毛求疵的话,也有副作用,就是写多了几个类,23333。
另外还有一点要注意,设计模式不能强行硬套,还要看具体场景,比如这里,因为业务逻辑比较固定,可以这样抽,但是有些业务逻辑经常变动或者角色间逻辑差异过大的,这种玩法就不是很适合了,可能还需要进一步的抽象。
日常开发应用示例二
App里有很多列表页,布局都是 RefreshLayout套一个Recyclerview,然后逻辑都是这样的:
- 数据初始化 (赋初值,解析各种传参,自定义Adapter初始化)
- UI初始化 (参数异常校验错误显示错误UI、RefreshLayout设置上拉刷新和下拉刷新逻辑、RecyclerView设置)
- 请求接口,更新UI(正常状态、异常状态)
没写一个列表页,都要重复一遍,太蠢了,一种解决方式是利用AndroidStudio模板来自动生成。
也可以像笔者一样利用:抽象
+ 泛型
+ 多态
+ 回调
来简化偷懒,核心还是 抽取变化
- 视图 → 列表可能显示不同的布局 → 由Adapter进行控制 → 关联不同的Bean
- 数据 → 列表可能显示不同的数据 → 由请求进行控制 → 关联不同的Request和Response → Response中包含一个Bean的列表,变化的是这个Bean
不难抽出三个变化的类:
- Bean → 与Adapter数据绑定,与Response里的list绑定
- Request → 不同列表请求接口和参数不一样
- Response → 不同列表请求接口响应结果不一样
可以定义成泛型,示例如下:
abstract class DefaultPrlRecFragment<D, Q : Serializable, S : Serializable> : BaseFragment() {
abstract val mAdapter: BaseQuickAdapter<D, BaseViewHolder>? // 适配器
abstract val mReq: Q // 请求
abstract val mObservable: Observable<Response<Bean<S>>> // 接口
protected var mData = ArrayList<D>() // 数据
}
复制代码
子类实现时,传入对应的类型即可,接着到逻辑抽象,先是数据处理这块:
// 读取各种传入数据或进行一些准备,返回true代表正常加载、false表示出现异常
abstract fun prepareData(bundle: Bundle?): Boolean
override fun initData(bundle: Bundle?) {
if (prepareData(bundle)) {
// 正常显示
} else {
// 显示异常页面
}
}
// 发起请求前的一些准备操作
abstract fun beforeRequest()
// 加载请求
protected fun loadRequest(isRefresh: Boolean = false) {
// 请求处理
}
// 请求响应内容解析,提取数据
abstract fun parseData(s: S): DataEntity?
// 解析后的数据类
inner class DataEntity(
var list: ArrayList<D>?,
var allRows: Int, // 总记录数
var pageNum: Int // 总条数
)
复制代码
再接着是视图,把交互都抽到一个接口中,然后在具体的业务逻辑回调:
private var mListener: InteractiveListener? = null
// 交互接口
interface InteractiveListener {
fun listEmptyCallback() // 列表空
fun listNormalCallback() // 列表正常显示
fun listItemClickCallback(position: Int) // 列表点击
fun listItemLongClickCallback(view: View, position: Int) // 列表长按
fun onRefreshCallback() // 刷新列表
fun onLoadMoreCallback() // 加载更多
}
// 抽象类(提供默认实现,不用重写全部方法)
abstract class SimpleInteractiveListener : InteractiveListener {
override fun listEmptyCallback() {}
override fun listNormalCallback() {}
override fun listItemClickCallback(position: Int) {}
override fun listItemLongClickCallback(view: View, position: Int) {}
override fun onRefreshCallback() {}
override fun onLoadMoreCallback() {}
}
// 添加交互接口
fun addInteractiveListener(listener: InteractiveListener) {
this.mListener = listener
}
复制代码
调用示例如下:
Fragment写完,接着就到怎么去用它了,继承这个类,传入三个数据类型,重写抽象成员和方法:
接着就是 填字游戏 了,示例如下:
只需三步,即可实现一个带分页功能的Fragment,又可以偷懒摸鱼了,美滋滋~
0x2、核心总结图
上述两个例子跟笔者做所业务有较强关联,应该很难直接搬运,不过借鉴应该是可以的。当然,笔者勉强算初窥门径,肯定有更好的实现方式,算是抛砖引玉,指出学习设计模式的重要性吧。接着总结一波之前的章节(面试速成必背),具体详细内容可移步至:《把书读薄 | 设计模式之美》 阅读学习,感谢~
概念与OOP
设计原则
设计模式
0x3、小结
最近杂事缠身,除了公司日常开发迭代,还要背八股文,东奔西走面试,累,但也收获不少,挺多感悟的(技术、学习、与人交流等),等挪了坑再来总结分享一波哈~
??? 掘金官方福利
? 前段时间申请了一波 掘金周边,本以为希望渺茫,结果上榜了,哈哈?,送一波小礼品哇? ~
抽奖方式
截止到 9月10日24点,评论区超过10人互动 (不包括我哈),评论区随机抽两只幸运儿? 分别送出 BlingBling✨✨ 的 掘金徽章一枚!!!
开奖时间:9月12日中午12:00,到时我会联系中奖的小伙伴哈,感谢 掘金官方 对本次活动的大力支持?!