面向对象之共享单车项目

面向对象之共享单车项目

最近项目在做一个单车项目,由于1.0版本催得很急,并且该项目是在另外一个单车项目上修改而来,因而最开始想的就是在之前的单车项目上增加些代码实现功能,结果在遇到很多的坑,而其中最坑的就是自行车状态的维护

自行车的状态

在开始的开发中,由于没有考虑很多,所有的状态都在SharedPreferences(简称SP)中存储,结果导致当后面考虑的状态越来越多的时候,有时连自己都不知道某个key值表示的哪种状态

需要考虑的状态:

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

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

面向对象

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

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

第一步:映射现实

自行车和Bike(自行车对象):
Bike映射的就是自行车,而自行车对于整个单车项目来说,是唯一的.
因此Bike必须是单例模式

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

第二步:状态的分类

在所有需要维护的状态中,需要将各种状态分离出来,各自归类到Bike和CyclingTask中.

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

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