引子
每次面试，都被问你会设计模式么，特意去看过《大话设计模式》，《head first 设计模式等书，刚看着挺神奇，看了几个后，在实际项目中总感觉用不上，会造成过度设计，代码臃肿等问题，明明简简单单一个类就能搞定的事，却要建好几个类。所以过了一段时间又忘了，面试官问的时候，我竟然一个答不上来，心里还对面试官一阵鄙视，你咋这么学院风呢。
为什么学习设计模式
很久以前，项目中有个简单的多平台分享功能，随着公司业务的扩大，不停的有新的功能加入，根据调用入口动态切换分享来源，一些业务是否显示，是否通知服务器等，不同入口展示的页面也不一致，所以所有分享的业务代码还分布在不同的页面中，每次的小修改都弄得我胆颤心惊，最近产品又要求所有分享页面都要修改成弹窗形式，还加其他功能，最终意识到不能再这样，把分享的业务逻辑单独抽离了出来，也让我坚定了认真的重新学习设计模式。通俗来说，设计模式能降低编程复杂度，减少bug，便于维护。
为什么要监听Activity,fragment生命周期呢
有的同学可能跟我一样遇到过Dilog 没关闭引起的Window Leaked，或者老版本的Volley异步线程导致的oom,RxJava没有 unRegister，使用了异步线程没有关闭，handler没有移除Runnable等，这些问题都只需要在Activity或者fragment Destroy时关闭即可，但是每次写重复的代码，是不是很丑陋，有时还会忘记呢，正好重新看了 Android 源码设计模式解析 这本书，尝试下用设计模式的方法来解决.
依赖倒置原则
（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
/** * Created by Administrator on 2016/7/27. */
public interface Destroyable {
void onDestroy();
}
import android.app.Dialog;import android.os.AsyncTask;
import java.util.ArrayList;import java.util.List;
/** * Created by Administrator on 2016/7/27. */
public class DestroyableManager {
private List<Destroyable> destroyableList = new ArrayList<>();
private void add(Destroyable destroyable){
destroyableList.add(destroyable);
}
private void remove(Destroyable destroyable){
destroyableList.remove(destroyable);
}
public void noticeDestroy(){
for (Destroyable destroyable : destroyableList) {
if(destroyable instanceof Dialog){
((Dialog) destroyable).dismiss();
}else if (destroyable instanceof AsyncTask){
((AsyncTask) destroyable).cancel(true);
} //TODO close anything in here
destroyable.onDestroy();
} destroyableList.clear();
destroyableList = null;
}
}
public class BaseActivity extends Activity{
DestroyableManager destroyableManager = new DestroyableManager();
@Override
protected void onDestroy() {
super.onDestroy();
destroyableManager.noticeDestroy();
}
protected void addDestroyable(Destroyable destroyable){
destroyableManager.add(destroyable);
}
}
