只关心零件的Buider

只关心零件的Buider

建造者模式的初衷是为了将对象的构建与表示分离，封装一个对象的不懂表现方式。但往往实习使用中，我们的需求并没有那么多的表现方式，且遇到最多的Builder也不是定义中的Builder。

==============

定义

传统定义：将复杂对象的构建与它的表示分离，使得同样的构建有着不同的表现方式。

实际使用的Builder：依照赋予的不同参数，去创建不同表现的对象。

这是我们最常见到的Builder形式。

embedManager = new EmbedManager.Builder(this, layoutResID)            .addToolbar(R.layout.widget_toolbar, R.id.id_tool_bar)            .addTopWidget(LayoutInflater.from(this).inflate(R.layout.widget_top_view, null))            .addBottomWidget(LayoutInflater.from(this).inflate(R.layout.widget_bottom_view, null))            .addCenterTipView(new NoDataTips(this))            .addLoadView(LayoutInflater.from(this).inflate(R.layout.widget_loading_view, null))            .build();

演化

实际过程中，普通建造者模式的使用场景并不是特别多。在实际需求中，最多的需求反而是参数的不确定。什么是参数的不确定呢？

通常我们给一个类传参时，使用这样的方式：

obj.setParam(int arg1,int arg2,int arg3,int arg3);

那么问题来了，如果我只有arg1,和arg2需要传递怎么办？

arg3传null? 增加新的重载方法？ 哦~这样的体验说实话并不好。有更好的替代方式吗？有的

就是上面你看到的形式。通常我们这样定义,依照代码注释，你可以很轻松的学会这样的设计技巧。

class EmbedManager {    private Object arg1;    private Object arg2;    private Object arg3;    public EmbedManager(Object arg1,Object arg2,Object arg3){        if(arg1 != null){            。。。        }        if(arg2 != null){            。。。        }        if(arg3 != null){            。。。        }        。。。。。    }    //负责创建EmbedManager的建造者    public static class Builder{        //arg1是必须参数        private Object arg1;        //arg2，arg3是可选参数        private Object arg2;        private Object arg3;        //必须参数通过构造函数传递        public Builder(Object arg1){            this.arg1 = arg1;        }        public Builder setArg2(Object arg2){            this.arg2 = arg2;            //设置成功后返回this本对象            return this;        }        public Builder setArg3(Object arg3){            this.arg3 = arg3;            //设置成功后返回this本对象            return this;        }        //最后负责创建的类        public EmbedManager build(){            EmbedManager em = new EmbedManager(arg1,arg2,arg3);            ...            em.setTitle("xxxx");            em.set~            em.set~            return em;        }    }}

优点

• 你可以很轻易的发现它的优点，将对象复杂创建过程进行封装，实现了解耦。

• 使用体验的优化，参数控制更加容易。

• 更灵活的配置化实现

误区

无论是原本的建造者模式，还是演化后的建造者模式，在合适的场景下都非常优秀，很难找到缺点。

这里就说一个演化后的建造者使用误区：

有些人因为喜欢演化后的建造者模式清晰的写法而使用了它。但它却用文档形式硬性的告诉你，我的这些个参数你必须都有，这并不是一个很好的使用。

既然使用了这样形式的配置化写法，就隐式的告诉了用户我的这些参数是可有可无的，这样用文档形式规定是非常容易出错的。