《设计模式》工厂家族
设计模式被分成了三种类型，这次来说一下创建型中的工厂家族（简单工厂方法，工厂方法模式，抽象工厂）。通过了解，三者之间的比較来加深对工厂家族的了解。
简单工厂:
工厂类中有必要的逻辑推断,依据client的选择能够动态的实例化相关类.去除了与详细产品的依赖。例：
在上述计算器的样例结构图中，假设我们要新加一个功能，不仅要添加预算类的子类，且还要改动运算类工厂，添加switch的case分之条件，这也就违背了开放封闭原则。
所谓的开放封闭原则：就是（软件实体类，模块，函数等）对扩展开放，改动封闭。
缺点:不符合开闭原则
工厂方法:
定义一个用于创建对象的接口,让子类决定实例化哪个类.使得一个类的实例化延迟到其子类。例：
上图是计算器的工厂方法结构图，当须要添加新的功能的时候，仅仅须要对应添加功能的运算类和工厂类，而不须要去改动原有的工厂类。
缺点:添加一个类,须要添加额外的开发量
长处:仅仅有扩展变化，没有改动变化。克服了开闭原则。
简单工厂VS工厂方法:
工厂方法把简单工厂内部逻辑推断移到了client代码来进行.之前添加功能须要改动原有工厂类，如今仅仅需改动client。 两者都是集中封装了对象的创建，使得更换对象不须要做大的修改就可实现，减少了耦合性。
抽象工厂:
提供创建一系列相关或互相依赖对象的接口,而无需指定他们详细的类。
结构图：
缺点：若要添加新功能，就要添加三个类，还要改动原有类。
长处：符合开放封闭，依赖倒转原则。
易于交换产品系列；详细的创建实例过程和client分离，client是通过抽象接口操纵实例，产品的详细类名也被详细工厂的实现分离，不会出如今客户代码中。
每一个模式都有自己的优缺点，怎样解决所用模式的缺点呢，这里提到一个反射技术：
格式：Assembly.Load("程序集名称").createInstance("命名空间.类名称")
对于反射个人不是非常理解，这里借用查到的资料来解释一下反射。 所谓反射就是依据编程语言提供的反射类，直接将字符串转化为类或方法，然后再进行调用。这样一来，在抽象工厂模式中，程序猿在client代码中能够不知道详细的类名，通过反射来将输入或者获取到的字符串转化为抽象工厂模式中的工厂类，再调用同名方法实例化产品类，这样一来就能够全然避免使用逻辑推断了。
使用反射能够弥补抽象工厂的不足。
工厂方法VS抽象工厂：
