android 设计模式6大原则之 开闭原则

 android 开闭原则 用日常程序语音来说就是面向接口编程吧。就是mvp 架构 是这个原则的最佳实践。

在android 源码与设计模式这书种，明显讲了有点乱。看到了最后才看出来就是面向接口编程的意思。

这个原则在实际开发中 使用的不是很多，整体架构 才会去使用吧。一般与单一原则一起使用。

简单的来说， 开闭原则在实际开发中 比较常见的使用场景 是 ，Base类中，比如 有一个BaseActivty 有

3个Activity 继承使用，如果需要关闭 所有Activity 实现退出程序。那么在base中 实现 activty管理逻辑，

最后关闭所有Activity就可以了。

 

再给大家举例，在

ViewPager + Fragmengt 实现刷新某一个fragemnt数据操作。

有一个操作就是 在 fragment中 getActivty,强制转换为 父类activity。然后调用父类activty的方式，在这个

方法里面写入逻辑， 获得需要刷新的 fragment ，传值或者 重新创建一个 。然后刷新viewpage.达到刷新

这个fragmeng的操作。但是10个fragment就要写10套逻辑，虽然可以抽取，但是刷新的数据什么的都不一样。

所有有一个方法，在适配器中写一个 刷新，方法。所有frament继承刷新方法，在里面实现刷新操作。调用

这个适配器，放入下面就可以实现刷新。

public abstract class BaseFragmentPagerAdapter extends FragmentPagerAdapter {

    private FragmentManager mFragmentManager;
    private List<String> tagList = new ArrayList<String>();

    public BaseFragmentPagerAdapter(FragmentManager fm) {
        super(fm);
        this.mFragmentManager = fm;
    }

    @Override
    public Object instantiateItem(ViewGroup container, int position) {
        tagList.add(makeFragmentName(container.getId(), getItemId(position)));
        return super.instantiateItem(container, position);
    }

    @Override
    public void destroyItem(ViewGroup container, int position, Object object){
        super.destroyItem(container, position, object);
        tagList.remove(makeFragmentName(container.getId(), getItemId(position)));
    }

    private static String makeFragmentName(int viewId, long id) {
        return "android:switcher:" + viewId + ":" + id;
    }

    public void update(int position){
        Fragment fragment = (Fragment)mFragmentManager.findFragmentByTag(tagList.get(position));
        if(fragment == null){
            return;
        }
        if(fragment instanceof UpdateAble){//这里唯一的要求是Fragment要实现UpdateAble接口
            ((UpdateAble)fragment).update();
        }
    }

    public interface UpdateAble {
        public void update();
    }
}

再给大家讲一个 很有用但是不常见的例子。就是封装网络 请求 时候 的一个操作。

就是 服务器返回一个 json，一般对应一个 object,或者arraylist。那么我们 是不是 可以把 这个类型传进入，

然后服务器返回的时候，统一解析在异步线程中解析对应的bean.返回回来。下面就是代码；

static Type getSuperclassTypeParameter(Class<?> subclass) {
     Type superclass = subclass.getGenericSuperclass();
     if (superclass instanceof Class) {
          throw new RuntimeException("Missing type parameter.");
     }
     ParameterizedType parameterized = (ParameterizedType) superclass;
     return $Gson$Types.canonicalize(parameterized.getActualTypeArguments()[0]);
}

//这一步是把 对应的object转换为 Gson解析的type.

// 下面这部就是 使用 gson和type 转为对应的object ,在使用的时候强制转换一道就可以了

Object o = new Gson().fromJson(response.getData(), handler.mType);

 

总结： 开闭原则 我个人认为比较难，架构师必备。需要对整个项目 逻辑十分清晰，先要

把某块业务逻辑先拆分为 单一原则，然后对这个块逻辑，实现一个base。或者接口。

使用场景：

1.代码重构时候，发现功能基本一样的时候。把 代码合并。

2.该业务逻辑 可以拆分为一块 ，并且代码实现逻辑不一致，但是功能一致。

例如，加载图片这个功能， 业务逻辑为 加载图片，单独一块。加载图片方式很多，框架也多。但是

功能都是把 imagview，和url 仍进去，最后 imageview绑定 图片。