Android项目重构的一些认识和思考

确切的说，本文是一篇读书笔记，阅读了三篇Android重构的文章：

Android项目重构之路:架构篇

Android项目重构之路:界面篇

Android项目重构之路:实现篇

上图是我阅读文章的作者给出的架构层次。一共分为四层：

1、界面层，负责数据显示，依赖于核心层和模型层。

2、核心层，是业务逻辑处理与UI逻辑处理，依赖于接口层和模型层

3、接口层，是网络请求相关，向服务器获取数据，依赖与模型层

4、模型层，是网络数据的实体类

       接口层与核心层通过接口低耦合，核心层与界面层通过接口低耦合。接口的使用涉及到三个方面：接口的调用，接口的实现，接口的注入。一个方法或一个类在使用的时候，调用形式是接口类，和具体实现的逻辑是实现类，不同 的实现类有不同的逻辑，但是调用的形式只有接口类这一个。java的特性，让当调用接口类的方法时，实际是运行对应实现类里的方法。因而，代码书写上，几乎不做改变（对被依赖的类而言），而具体的业务逻辑写在了实现类里，可以根据需求新建不同的实现类或修改。回到这个架构上来，界面层与核心层通过接口耦合，如果核心层业务逻辑改变了，知识改变了接口的实现类，接口并不变，界面层的代码可以保持不变。

      android-priority-jobqueue框架用于接口层，EvenBus和butternife放在界面层。

     数据获取，数据处理，数据展示直接写在Activity或Fragment里，那么activity和fragment就会显得很重，代码量很大，不利于维护，而引入架构后，就把数据的获取，数据的处理单独写在其他模块或类里，然后在Activity或Fragment里调用即可。而数据的展示，必须写在Activity或Fragment，不过现在安卓出现了Bind Date技术，可以在视图里绑定数据了。这样数据的展示也可以不必写在Activity或Fragment里。就能大大减少Activity或Fragment的代码量。此时Activity和Fragment扮演的角色就是控制者，管理者，是交互的管理中枢。

       我想，我们之所以引入各种框架，就是要把Activity和Fragment的代码量降低下来，形成一个个单一的职责或者功能模块，高级模块和上层职责并不要知道太多低级模块或下层职责的具体实现，建立依赖时尽量沿着继承体系来，对朋友类依赖。在这样的过程中，有共有的变化的部分抽象出来，做成接口或者抽象类/抽象方法（面向接口的编程），同时每个接口要对应单一的功能，接口方法的多少取决于项目所合适的粒度，过多和过少都不是好的过程。在这个过程中，会形成继承体系，以便更好的管理，子类尽量不要覆盖父类的方法，子类重载父类的方法时，方法参数要比父类的更宽松，而子类实现父类的抽象方法时，返回的数据类型要比父类的更严苛。在这个过程中，努力做到高内聚，低耦合，有利于通过新增类，增加代码的方式来满足需求的变化，而不是通过修改原来的代码来满足新需求。

如何确定抽象部分或者说哪些部分需要抽象出来？

答：共有的、变化的部分需要抽象出来。当我们在开发项目的时候，预估到需求变化的方向，这种变化存在重复性，把这重复性中相似阶段（这个阶段常表现为变化的）做成抽象，而不同的阶段写成细节和具体。