面向对象之共享单车项目

最近项目在作一个单车项目,因为1.0版本催得很急,而且该项目是在另一个单车项目上修改而来,于是最开始想的就是在以前的单车项目上增长些代码实现功能,结果在遇到不少的坑,而其中最坑的就是自行车状态的维护web

自行车的状态

在开始的开发中,因为没有考虑不少,全部的状态都在SharedPreferences(简称SP)中存储,结果致使当后面考虑的状态愈来愈多的时候,有时连本身都不知道某个key值表示的哪一种状态网络

须要考虑的状态:svg

* 自行车是否有骑行任务
* 自行车的网络是否可用
* 自行车是否处于暂停状态
* 自行车开锁是否成功
* 自行车暂停是否成功
* 自行车骑行结算是否成功
.....

自行车的每种状态,还须要考虑没有网络,用户忽然关机,应用程序崩溃,和后台交互失失败等各类情形,
最后致使的就是,看着代码中SP中各类的设置状态值和获取状态值,一脸懵逼.
估计再过一段时间,就是傻逼的模样,项目根本没有办法维护

面向对象

1.0版本在修修补补中,终于发布,迎来一段空闲期,也知道若是继续这样下去,项目根本没有办法进行下去,因而抓住这段空闲期进行重构代码,而首先想到的就是用面向对象的思想,对全部的状态进行维护code

其实在上面的各类状态的维护中,只牵涉到两个对象:Bike(自行车对象)和CyclingTask(骑行任务对象),后面就是对两个对象的分析xml

第一步:映射现实对象

自行车和Bike(自行车对象):
Bike映射的就是自行车,而自行车对于整个单车项目来讲,是惟一的.
所以Bike必须是单例模式

骑行和CyclingTask(骑行任务对象)
每次从开锁到锁车结算,不管中经历过什么,就算完成一次骑行,而一辆自行车能够进行屡次的骑行,
所以CyclingTask就是多例的.
而在实际中,一辆自行车不管进行过多少次骑行,在某个时刻,要么没有骑行任务,要么只能有一个骑行任务,
所以Bike中须要持有一个CyclingTask的引用,
该CyclingTask的引用要么指向为null,要么指向一个CyclingTask的实例

第二步:状态的分类开发

在全部须要维护的状态中,须要将各类状态分离出来,各自归类到Bike和CyclingTask中.

例如:
自行车网络是否可用,它是自行车的一项属性,虽然它会影响到骑行任务的开始和结束结算等,
可是它并非骑行任务的组成一部分.
骑行只要有开始和结束,就是一次骑行任务.
所以,是否有网络的状态,须要归类的Bike中.

基本上完成上面的两步,各类逻辑已经清晰明了,即便后面还须要考虑某种临界状态,只须要相关对象中添加对应属性便可it