拒绝纸上谈兵--萌新开发手册(踩坑分享之封装)

凄惨红 · · 295 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

首先声明一下,我也是菜鸡,本文内容纯属自己从项目获得的经验用来分享,如果文章中有什么观点或说法不对的地方,欢迎大佬们看到了及时纠正,不过对于大部分萌新来说,文章应该总体上是没有什么错的。

废话不多说,下面开始:

说起封装,有的人觉得很简单,有的人会觉得无从下手,无论是哪种情况,想要写出比好的封装,最简单的方法就是被坑了。为什么这么说呢,因为只有当你自己被自己写的代码坑到时,你才知道这里该封装,该如何封装,坑的越痛,记忆越深刻,别问我怎么知道的,我不想说。当然,既然我在写这篇文章,目的就是希望萌新们少踩点坑,有些东西如果能够一开始就做好,岂不美哉。
  上面说的都是比较虚的东西,下面我们来点干货,到底在真正的项目中,我们在那些地方需要封装?应该怎么去封装?

1.对第三方库的封装

使用了蛮多第三方库,也加了不少群,发现很多萌新(甚至是工作了近一年的准初级程序猿)在使用别人的库时,都喜欢直接照着文档就在自己的项目中到处使用,完全没有意识到这么写的隐患。如果一个库需有很多配置参数,相信大部分人还是知道,应该自己写个工具类来进行统一配置,但是当一个库的用法比较简单时,许多人就喜欢直接到处写了,这样其实会有很多问题的。
  首先,耦合过强不易替换。不对第三方进行封装,最直接的影响就是不能够快速替换,以我们最常见的图片加载库来说,早几年比较流行的图片加载框架是一个叫做ImageLoader的库。试想一下,一个app中,使用图片加载的地方,少则十几处,多则几十处,如果你每个地方都引用了ImageLoader这个类,那么当你某一天需要换掉这个库的时候会发生什么?没错,你需要到处修改,虽然studio有重构快捷键和全局查找功能,可以方便的找到所有引用的地方,但是明明可以靠代码解决的问题,又何必给自己挖坑呢。
  其次,不易修改。有些库,可能本身配置就比较少,刚好它的默认配置就能满足你当前的需求,这时,很多人也就直接用了。那么,你们有没有想过,后面你发现需要修改某一个属性配置时要怎么办呢?没错和上面类似的,你又要去到处该,简直就是地狱了。
  那么我们该如何对第三方进行封装呢?这里只说几点我认为的基本要求,1.第三方库的所有类只能出现在自己的封装类中,项目里其他任何地方不应该对第三方库产生引用,只有这样才能做到,你想替换这个库时,只进行最少的代码修改。2.如果项目本身对一个库的配置没有太多变化的时候,尽量不要把配置过多的暴露到封装类之外,这样做可以保证封装类调用的简洁性。
  下面以一个下拉刷新库为例进行简单封装
  刷新库SmartRefreshLayout--https://github.com/scwang90/SmartRefreshLayout
  许多萌新,基本上拿到一个库就开始照着别人的文档往项目加了,比如这样用

public class RefreshActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        //下面示例中的值等于默认值
        SmartRefreshLayout refreshLayout = (SmartRefreshLayout)findViewById(R.id.refreshLayout);
        refreshLayout.setPrimaryColorsId(R.color.colorPrimary, android.R.color.white);
        refreshLayout.setDragRate(0.5f);//显示下拉高度/手指真实下拉高度
        refreshLayout.setRefreshHeader(new ClassicsHeader(this));//设置Header
        refreshLayout.setRefreshFooter(new ClassicsFooter(this));//设置Footer
        refreshLayout.autoRefresh();//自动刷新
    }
}

调试了一下,没什么问题,然后就开始在项目各处使用。突然有一天,产品经理发话了,这个刷新样式不好看,重新设计,然后你就一脸懵逼了,你这个设置写的到处都是,只能去一个一个改了。当然这个问题其实是个很基础的问题,基本上有个把月经验的同学都知道需要统一配置,所以也许他们会这么写:

public class RefreshActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        //下面示例中的值等于默认值
        SmartRefreshLayout refreshLayout = (SmartRefreshLayout)findViewById(R.id.refreshLayout);
        RefreshLayoutUtil.refreshLayoutConfig(refreshLayout ,this);
        refreshLayout.autoRefresh();//自动刷新
    }
}
=========================分割线==================================
 public class RefreshLayoutUtil {
        public static void refreshLayoutConfig (SmartRefreshLayout refreshLayout, Context context) {
            refreshLayout.setPrimaryColorsId(R.color.colorPrimary, android.R.color.white);
            refreshLayout.setDragRate(0.5f);//显示下拉高度/手指真实下拉高度
            refreshLayout.setRefreshHeader(new ClassicsHeader(context));//设置Header
            refreshLayout.setRefreshFooter(new ClassicsFooter(context));//设置Footer
        }
    }

这也就是我上面说的对第三库进行统一封装的一部分,我们这里采用的是对通用配置进行统一封装,好了现在产品经理告诉我,你想改几次样式?来来,随便改,皱下眉头算我输。
  拥有了上面的小技巧,大家终于能轻松一点。然而,你刚躺下,被子都没捂热,突然产品经理一个电话,XX你的app刷新就崩溃了。然后你就开始debug看了,最后发现不是你的问题,是这个库本身就有bug,然后你打算上github上提给作者,一看,我去,作者竟然已经宣布停止维护了。那怎么办?有些同学会选择把库下载下来,自己试着修改,不过碍于水平有限,大部分人在尝试了一下修改然后无果后都会选择换成另一个库。
  好嘛,我们现在又来换库试试,去掉库依赖,我去,竟然有几十个类和xml报错,这次是真的绝望了,看来只能删代码跑路了。。。
  开个玩笑,我们肯定不可能跑路的,只能硬着头皮改。关键是改之前你要考虑,下次再出这个问题怎么办呢?当然还是通过封装来解决了:

public class RefreshLayout extends SmartRefreshLayout {
    public RefreshLayout (Context context) {
        super(context);
    }

    public RefreshLayout (Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public RefreshLayout (Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

    public void setOnRefreshListener (final RefreshListener refreshListener) {
        setOnRefreshListener(new OnRefreshListener() {
            @Override
            public void onRefresh (com.scwang.smartrefresh.layout.api.RefreshLayout refreshlayout) {
                refreshListener.onRefresh((RefreshLayout) refreshlayout);
            }
        });
        setOnLoadmoreListener(new OnLoadmoreListener() {
            @Override
            public void onLoadmore (com.scwang.smartrefresh.layout.api.RefreshLayout refreshlayout) {
                refreshListener.onLoading((RefreshLayout) refreshlayout);
            }
        });
    }

    public void startRefresh () {
        super.autoRefresh();
    }

    public void startLoadMore () {
        super.autoLoadmore();
    }

    public interface RefreshListener {
        void onRefresh (RefreshLayout refreshLayout);

        void onLoading (RefreshLayout refreshLayout);
    }

    public void finishRefreshing () {
        if (!isRefreshing()) {
            return;
        }
        super.finishRefresh();
    }

    public SmartRefreshLayout finishLoadmore () {
        if (!isLoading()) {
            return null;
        }
        return super.finishLoadmore();
    }
    .......
    省略部分配置代码
    .......
}

可能有的同学一看这代码就疯了,说,这不是闲的蛋疼嘛,为什么要自己继承一次,而且还把父类的方法重新封装了一次?
  其实一开始我已经说得很清楚了,对于第三库的封装就是要避免外界直接引用第三库的任何类或方法,试想一下,如果我们一开始就是这么写的,当你去掉了这个刷新库的依赖时哪里还会报错?没错,如果你遵照着上面的原则进行封装,你会发现仅仅只有这个类会报错,其他任何类和xml布局都不会报错,不报错也就说明其他地方不用做任何修改,你只需要接入你的新库,然后修改自己这个封装类,也许你的新库中刷新方法不叫autoRefresh,就叫refresh,不过没什么关系,你只需要把super.autoRefresh改成super.refresh就行了。其他的类其实依然是调用你的封装方法startRefresh,所以立即就能生效了。


上面说的是对第三方控件的封装,下面来说说对第三方工具类类型库的封装,其实原理都一样,只要具备了上面的封装思想,再来封装工具类也就举一反三了。下面以一个图片选择库为例:
  https://github.com/LuckSiege/PictureSelector

  public static void chooseImage(Activity activity,int maxCount){
        PictureSelector.create(activity)
                .openGallery(PictureMimeType.ofImage())//全部.PictureMimeType.ofAll()、图片.ofImage()、视频.ofVideo()
//                .theme()//主题样式(不设置为默认样式) 也可参考demo values/styles下 例如:R.style.picture.white.style
                .maxSelectNum(maxCount)// 最大图片选择数量 int
                .minSelectNum(0)// 最小选择数量 int
                .imageSpanCount(4)// 每行显示个数 int
                .selectionMode(PictureConfig.MULTIPLE)// 多选 or 单选 PictureConfig.MULTIPLE or PictureConfig.SINGLE
                .previewImage(false)// 是否可预览图片 true or false
                .isCamera(false)// 是否显示拍照按钮 true or false
                .isZoomAnim(true)// 图片列表点击 缩放效果 默认true
                .sizeMultiplier(0.5f)// glide 加载图片大小 0~1之间 如设置 .glideOverride()无效
                .setOutputCameraPath("/CustomPath")// 自定义拍照保存路径,可不填
                .enableCrop(false)// 是否裁剪 true or false
                .compress(true)// 是否压缩 true or false
                .compressMode(PictureConfig.LUBAN_COMPRESS_MODE)//系统自带 or 鲁班压缩 PictureConfig.SYSTEM_COMPRESS_MODE or LUBAN_COMPRESS_MODE
//                .glideOverride()// int glide 加载宽高,越小图片列表越流畅,但会影响列表图片浏览的清晰度
                .withAspectRatio(1,1)// int 裁剪比例 如16:9 3:2 3:4 1:1 可自定义
                .hideBottomControls(true)// 是否显示uCrop工具栏,默认不显示 true or false
                .isGif(true)// 是否显示gif图片 true or false
                .freeStyleCropEnabled(true)// 裁剪框是否可拖拽 true or false
                .circleDimmedLayer(false)// 是否圆形裁剪 true or false
                .showCropFrame(true)// 是否显示裁剪矩形边框 圆形裁剪时建议设为false   true or false
                .showCropGrid(false)// 是否显示裁剪矩形网格 圆形裁剪时建议设为false    true or false
                .openClickSound(false)// 是否开启点击声音 true or false
                .cropCompressQuality(80)// 裁剪压缩质量 默认90 int
                .compressMaxKB(200)//压缩最大值kb compressGrade()为Luban.CUSTOM_GEAR有效 int
//                .compressWH() // 压缩宽高比 compressGrade()为Luban.CUSTOM_GEAR有效  int
//                .cropWH()// 裁剪宽高比,设置如果大于图片本身宽高则无效 int
                .rotateEnabled(false) // 裁剪是否可旋转图片 true or false
                .scaleEnabled(true)// 裁剪是否可放大缩小图片 true or false
                .forResult(PictureConfig.CHOOSE_REQUEST);//结果回调onActivityResult code
    }

好了,完了。这也叫封装?没错,这也叫封装了。只是相对来说,我们这种封装算是比较死的,因为各种属性都没有给出修改的方法,但是你要相信就算是你仅仅这样简单封装了一下,也绝对好过你到处去引用第三方库的类很多。原因嘛就不再重复了,上面已经说得很清楚了,这个封装虽然简陋,但是你想让他变灵活的话大可以自己修改下。对于像这种属性比较多的库建议使用builder模式进行封装,这样调用和修改都比较简单,具体封装代码这里就不再写了,有兴趣的同学可以自己尝试下。

注意:并不是所有库都一定要进行封装,有些库可能会由于某些原因没有办法进行很好的封装,比如Butter knife,rxjava。当然我这里说的不能很好的封装并不是指都完全不封装,而是指可能无法完全按照我上面说的几个原则进行封装,比如rxjava,他涉及很多类和方法,你要完全达到使用时不直接调用它的类基本上要封装很多代码,这时我们可以退而求其次,只封装一些通用配置属性。而像Butter knife这个库则基本上处于完全无法封装的状态。
  说句题外话,在有其他解决方案的时候强烈不建议使用类似于Butter knife这种库。Butter knife除了能偷懒少些几个findView以外,基本上毫无卵用,但是这种库最大的问题就在于耦合很高,你的项目一旦加入了这种东西,想再去掉就很麻烦了,这也是我为什么一直不用Butter knife的原因,如果你真的很讨厌写findView,我建议你使用官方的dataBinding或者使用kotlin开发,他们都能解决findView的问题,而且效果远比Butter knife好多了。当然了,这里纯属个人见解,如果你觉得Butter knife好用的话,那就继续用吧
  如何判断一个第三方库该不该封装?能不能封装?很简单,如果一个库需要的封装代码过多时,就可以考虑只简单封装一下,让外界引用几个第三方库的类也没关系。当然了,你要会风险评估,如果这个库有大概率会被替换掉的话,就要一开始就封装好。目前来说,像rxjava这种,完全封装的话,意义就不大,首先它涉及的东西太多,要封装肯定需要自己写很多东西,其次这种库基本没什么可替代的,所以对于你来说一般只会考虑用不用,如果你本来用了,现在要去掉它的话,不管你封不封装,基本上都要大面积修改代码,那花大力气封装也就是浪费时间了。


2.项目中的逻辑封装

这里来说说对项目中部分逻辑的封装,其实有了上面对第三方库的封装,那么对自己项目中什么东西该封装,大家心里应该都有点数了,还是直接举个栗子,请看如下代码:


        EditText nameTV = findView(R.id.name);
        EditText sexTV = findView(R.id.sex);
        EditText ageTV = findView(R.id.age);
        nameTV.setFocusable(false);
        nameTV.setClickable(false);
        sexTV.setFocusable(false);
        sexTV.setClickable(false);
        ageTV.setFocusable(false);
        ageTV.setClickable(false);

  这是一个很常见的需求,某些界面可能既是编辑页面又是详情界面,这时可能就需要我们动态改变输入框的可点击状态,上面这么写看上去似乎除了比较丑陋以外并没有太大问题,但是现在需求又双叒变了,进入编辑时我们要清空每个输入框文本并更改提示文字,好嘛,你可能不得不这么改:

        EditText nameTV = findView(R.id.name);
        EditText sexTV = findView(R.id.sex);
        EditText ageTV = findView(R.id.age);
        nameTV.setFocusable(false);
        nameTV.setClickable(false);
        nameTV.setText("");
        nameTV.setHint("请输入");
        sexTV.setFocusable(false);
        sexTV.setClickable(false);
        sexTV.setText("");
        sexTV.setHint("请输入");
        ageTV.setFocusable(false);
        ageTV.setClickable(false);
        ageTV.setText("");
        ageTV.setHint("请输入");

  有木有感觉很蛋疼?没有?那我告诉你,我这个界面其实有15个输入框,好嘛,你去改改看。那么我们换一种方法来写试试:

        EditText nameTV = findView(R.id.name);
        EditText sexTV = findView(R.id.sex);
        EditText ageTV = findView(R.id.age);
        editTextConfig(nameTV,sexTV,ageTV);

=========================分割线=======================================

 private void editTextConfig (EditText... editTexts) {
        if (editTexts == null || editTexts.length == 0) {
            return;
        }
        for (EditText editText : editTexts) {
            editText.setFocusable(false);
            editText.setClickable(false);
            editText.setText("");
            editText.setHint("请输入");
        }
    }

  这下你想加任何配置都只需要修改editTextConfig方法即可,你15个控件也罢,只需要在参数列表传入就行。可以看出,这里我们仅仅是封装一个简单的内部方法,就大大提高了代码的可维护性,相信大家看了这个例子已经明白封装有多么重要了。

  好了,该讲的也差不多讲完了,项目中的封装,这个真的要靠自己去实践,我这里也只能分享一个简单的例子,希望大家能够举一反三。最后就说说我个人觉得项目中那些东西是必须封装的:

  • 复杂的逻辑代码。把相同的复杂逻辑代码到处写,改的是后绝对虐哭你。
  • 出现频率非常高的代码。例如对项目中的所有金额进行小数两位四舍五入,这个逻辑本身很简单,代码也只有一行的样子,当时如果你到处写的话,突然产品经理抽风要精确到3位,你怎么办?所以说,出现频率很高的代码,哪怕只有一行,也应该封装一次。
  • 特殊的业务逻辑代码。某些项目中特有的业务逻辑,可能本身出现次数不是太多4到5次吧,逻辑也不复杂,20行左右吧,你是不是又想偷懒不封装?是不是觉得反正才那么几处,大不了就是复制粘贴嘛。ok,你改完上线,然后又双叒被产品经理骂了,原来这块逻辑本来出现在5个地方,结果你只改了4个,漏掉了一个地方没改。

  以上的就是基本上来讲必须要封装的,不过最后一条的定义其实比较模糊,这个只能自己根据经验去判断。现在你应该清楚了,程序员封装不是仅仅为了偷懒,少些代码。不封装的话,多复制几遍都只是小问题,冰山一角而已,真正后期维护才是整个冰山。


  好了,本文到这里就结束了,以上观点纯属个人看法,如有不同见解欢迎指教。后面我还会继续分享我的踩坑日记,欢迎大家持续关注

  我的开源项目:MVP框架库

本文来自:简书

感谢作者:凄惨红

查看原文:拒绝纸上谈兵--萌新开发手册(踩坑分享之封装)

295 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet