博客封面.jpg
前言
阅读《Java 编程思想》，《Android 源码设计模式》这两本书后，发现了以往编码过程中有很多代码可以优化的点，以及当时的优化方案，所以记录下来。
从事 Android 开发快一年时间了，对编码有了些感悟，项目需求变更时，我们最好不要直接修改原有代码，最好使用添加的方式来实现，避免破坏原有代码的稳定，最好定期进行部分重构，及时清除代码中的“垃圾”。
单一责任原则
一个类应当包含某功能的全部流程，遵守该选择可提高代码的逻辑清晰度，降低代码耦合，便于以后维护。
- 目前案例
- 在某sdk项目中，账号绑定手机邮箱，账号升级，游客账号升级等功能(下面统称为账号升级)是一个让人头疼的东西，因为该流程需要4-5个页面做跳转，最后根据不同流程，显示对应的UI，如何将信息在这几个页面传递呢？最初设想用bundle来临时存储绑定信息，但缺点就是每次跳转到新的页面，就要马上把上个页面的bundle取出来，在需要多个页面跳转时，bundle就不适合该场景了。
- 方案1:使用SharedPreference,建立一个 BindInfoHelper 类，通过set,get方法将用户信息存储到sp中，这样就避免每次转存信息。因为流程最后要用之前存储的信息来显示不同的UI，所以根据单一责任原则，BindInfoHelper类应当在内部做判断,Actvity,Fragment 就根据该状态值显示UI
- 方案2:可以使用sqlite数据库存储信息，但当时时间紧迫，就选择了方案一
里氏替换原则
在《Android 源码设计模式》的定义是:一个类型为T1的对象O1,替换代码中类型为T2的对象O2,如果不出现异常，说明t1是t2的父类。
- 里氏替换的原理基于 Java 三大特性（封装，继承，多态），Java的父类中实现的方法，子类中一定存在同种方法，反向推导不成立。
- 目前案例
- 在某助手app中，由于项目工程比较大，如果要将原有网络框架由 Volley 替换成 Retrofit（在没有将网络框架抽象的情况下），将会是件非常棘手的事情，每个调用都需要修改，谁可以保证不会出错呢？此时利用里氏替换原则，我们应该把网络框架抽出一层来，具体的网路框架继承或者实现该抽象类（接口），以后需要替换的时候只要修改具体实现类，大大减少了工作量。
