源码阅读所思所想

下午看了大量的源码，从代码的设计角度以及注释规范性方面自己深有感触。首先读源代码给我最为明显的一个感觉就是复杂的回调（方法回调，接口回调），除此之外就是接口，继承，类与类、类与接口、接口与接口之间的复杂关系，再有就是反射，泛型，注解等最新技术的运用。规范性方面就是注释的格式一般最上边是方法功能说明，然后是@param说明，最后@return返回值说明。

“Class<>和User.class作为参数的关系”

有关类对象方面我这里要强调的就是类对象作为方法参数需要注意的问题。我们在定义方法的时候一般是这样的add(Class<>T t){…}(“格式显示问题T在‘<>’内部”)，而在实际方法调用的时候是add（User.class），在传入这个具体的User.class的时候T的具体类型便已经被确定为User了。

抽象类抽象方法的妙用以及BaseActivity的好处

下午在学习Z_COMIC项目的时候详细了解了项目整体的MVP架构模式，与我之前的MVP架构最大的区别就是Activity的设计，Z_COMIC中采用的是一个抽象的实现了RxAppCompatActivity的BaseActivity抽象类，在该抽象类中定义了几个抽象方法（将实现交给调用方），在重写的OnCreate(…)方法中通过回调抽象方法获得活动创建必须的参数具体实现则交给实现类完成，这样在我们具体的Activity类中就没有了有关活动生命周期相关方法的重复编写，从代码简洁性的角度来看的话，Activity内部少了很多业务逻辑相关的代码。有关View的操作方面同样是通过定义相关的IView接口抽象方法来实现（与后台交互含参方法，不含参方法）。

泛型的用处和几种表现形式

泛型在应用中主要有以下几种形式 <>(？)、<>(T)、<>(？extends A)、<>(？super A)主要出现在类方法以及接口的定义上，同样是一种将具体实现交给调用方的行为。从项目的设计角度来看的话泛型具备代表多个具体类型的功能，通过使用泛型大大增强了代码的复用性。

从面向接口编程和继承谈业务扩展

业务不是简单的数据库的回调而是数据库回调的组合，宏观表现是业务功能微观本质则是各种事务的组合，事务是对数据库操作的抽象，而业务是对事务的抽象，功能则是包含前后端整体的一个宏观表现。业务的扩展有多种形式：1. 接口方法的添加。2. 增加新的接口。3.接口相互继承。这是从业务扩展功能增加的角度来看的。而另外一点是业务变改，业务变更则要求项目整体关联度要低从项目可维护性的角度来思考的话增加新的接口是最好的方式。