标签：style blog http color 使用 ar strong 2014 div
设计模式（创造型）
目录
吐槽：周末+中秋+生日，为了明天而在家写代码的有木有。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
擦，这台电脑居然没装Eclipse，只能手写了。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
个人概括：创造型的设计模式一般是用来为业务层或者逻辑层提供底层实现类初始化策略的设计思路。
简单来说：就是用来创建对象的模式。
本次集成我使用的策略：
抽象工厂模式：用于创造对象
建造者模式：用于初始化对象
工厂模式/静态工厂：用于对建造者模块再次抽象（此处的代码在简单工厂中会有描述）
具体步骤：
场景准备： 一堆杂乱的实现类 (A1,A2,A3) (B1,B2,B3) (C1,C2,C3)
整体的设计步骤 -> 1 对实现类进行抽象，抽象出通用特性（这是创造型设计模式的核心）
（A1，A2，A3）抽象出接口A、(B1,B2，B3)抽象出接口B。。。。。。。
2 定义一个或多个接口里面有个方法用于获取第一步抽象出的A,B,C接口的子类....
interface ManagerService { public A getAInstance();
public B getBInstance();
public C getCInstance();
....
}
3 编写ManagerService接口的实现类Factory1,Factory2,Factory3;
4 每个Factory在实现getInstance方法的时候，可以自由搭配不同的实现类，比如
@override
public A getAinstance(){
return new A1();//return new A2();
}------到此就是工厂模式的框架
/** 扩展代码--用于初始化NEW出对象的属性
通过了这一层的封装，最重要的不仅仅是为了NEW 一个实现类A1，B2，C1...
而是为了更多的扩展：对接初始化对象的属性的扩展。
1 定义一个接口用户build对象属性
interface Builder{
public A bulid();
}
2 实现接口Builder类BuilderSampleA,BuildSampleB
@overrider
BuilderSampleA{
A a;
public BuilderSampleA(A a){this a = a;}
public A bulid(){
a.setxxx
a.setxxx
....
}
}
3 定义一个控制类Create用于控制需要初始化的方式,他接收Build的实现子类
public class Create {
public Object execute(Builder b){
return b.build();
}
}
4 每个Factory在实现getInstance方法的，可对比上面扩展代码之前的实现
@override
public A getAinstance(){
// return new A1();
Create c = new Create(new BuilderSampleA(new A1()); //这个工厂就是初始化A1的，所以这里可变的只有Builder的子类，而这个SamplerA的Builder利用上述方法也可以进行继续抽象和工厂化
return c.execute() //但个人建议到了这个层面似乎可以考虑用静态工厂的方式比较好，毕竟初始化的参数得策略并不会太多，这里就不再扩展了。
}
**/
5 客户端的调用过程-最小知道原则：暴露ManagerService接口以及具体的完成调用的工厂即可
示例这是创造A1实现类的过程。比如Factory1,2,3分别对应了A1,2,3
ManagerService manager = new Factory1();//无论创造哪一种A的实现类，只有这里标红的地方是需要修改的。
A a = manager.getAInstance();
/** 扩展后其实对于客户端来说也是一样的，或许getAInstance(String type)方法的入参会有所不同,通过type来选择哪一种sampler
ManagerService manager = new Factory1();
A a = manager.getAinstance(“samplerA”);
**/
看完了UML图后，现在我们来拆分整个创造型模式的各种策略
图片摘自百度百科
step 1 对底层实现类进行抽象成一个公用的接口
step 2 编写一个创建实例的控制层，根据入参的不同NEW出不同的实现类
个人评价
优点：静态工厂方法的实质是将客户端的逻辑封装到了服务端，对于代码而言确实是少了很多，当逻辑不多并且相对稳定不变的情况下，这样的策略还是很不错的。
缺点：缺点也很明显，当逻辑复杂时，代码的可读性并不高（大量的IF/else）,另外如果每次新增一项业务时，需要对类的内部进行修改，严重违反开闭原则。
解决方案：可通过工厂模式解耦业务逻辑，一个IF就是一个工厂类，然后根据工厂类抽象出一个管理工厂的接口。客户端只需要知道管理工厂的接口与工厂类即可。
图片摘自左潇龙博客
step 1 对底层实现类统一抽象出一个接口
step 2 定义一个工厂管理接口，用于统筹的NEW 出实现类
step 3 根据业务场景的数量制造对应的工厂类去实现工厂管理接口NEW出具体的底层实现（相当于把简单工厂里面的IF/ELSE变成了一个一个的类从而解耦业务逻辑）
step 4 由于工厂类是负责管理NEW的过程，也可以理解为封装的过程，所以这里可以再引入--建造者模式
个人评价：非常不错的的封层思想，通过工厂的封层使得类的初始化变得更为方便了。
缺点：暂没有想到，工厂类和产品类可能会很多，但是我觉得是必要的。
这里的步骤我就不再细致写了
等同于工厂模式，唯一的区别在于接口不再是单一方法，所以工厂生产的是一套组件。
个人评价 等同于工厂模式。
建造者模式是针对实体类进行属性的初始化
step 1 定义一个Builder接口
step 2 实现Builder接口的类其实就是一个个初始化参数的策略
step 3 创建一个Creator类用于统一管理Builder的子类，
其实到这里step 2 就可以了客户端是 Builder b = new BuilderSampleA(A a); b.build(); 这样完成了调用。
如果写了step 3，客户端就是 Creator c = new Creator(new BuilderSampleA(A a));c.execute();
不知道大家是否能明白为什么要Creator呢？
答：其实我个人理解是为了再次封装。参照静态工厂方法里面的示例。
原型模式我已经很少用了，大致是继承Cloneable接口，然后使用父类的Object的clone方法吧。
如果是深度克隆，那么下一层的对象也需要重写。
所以复杂对象用这方式并不方便，或许有更好的策略吧关于clone方法上的。
我是用JSON方式来完成克隆的，蛮方便的。
Object-->Json--->Object
主要的参考资料：
大话设计模式
百度百科
http://www.cnblogs.com/zuoxiaolong/p/pattern26.html
标签：style blog http color 使用 ar strong 2014 div
原文地址：http://www.cnblogs.com/sunfan1988/p/3961006.html
