反射机制剖析（一）：谈谈工厂家族

工厂用来隐藏产品创建细节

 

简单工厂

好处：客户不用知道具体电视——长虹的组装过程，是在工厂内部完成创建电视过程的。

不足：增加电视，需要修改工厂，增加if语句或者switch分支，又得对稳定代码重新测试。

 

工厂方法

好处：

对简单工厂中的工厂继续划分职责，从而很好的支持OCP原则开放扩展，关闭修改

适合单一系列产品的创建

不足：

如果是多个系列产品，也就是有多个工厂

选择判断问题依然存在，客户端需要决定实例化哪一个工厂。

如果再增加洗衣机等，会增加很多类。

 

抽象工厂

优点：

对产品的增加支持OCP原则

可用于多个系列产品的创建

缺点：

如果增加一个系列，至少增加三个类，比如洗衣机接口、洗衣机型号一、洗衣机型号二，还需要修改工厂接口、型号一工厂、型号二工厂。（对产品系列的增加不支持OCP原则）

 

利用反射改善

class 工厂
    {  
        //命名空间  
        private static readonly string AssemblyName = "抽象工厂";  
        // 从xml中读取equip值：电视机/笔记本
        private static readonly string equip = ConfigurationManager.AppSettings["equip"];;  
  
        public static 电视机 生产电视机()  
        {  
            //字符串： 抽象工厂.电视机型号*  
            string classname = AssemblyName + "." +  "电视机" + equip;  
  
            //反射，返回电视机类型的 电视机型号* 类的实例  
            return (IUser)Assembly.Load(AssemblyName).CreateInstance(classname);  
        }  
 
public static 笔记本 生产笔记本()  
        {  
            //字符串： 抽象工厂.笔记本型号*  
            string classname = AssemblyName + "." +  "笔记本" +equip;  
  
            //反射，返回电视机类型的 笔记本型号* 类的实例  
            return (IUser)Assembly.Load(AssemblyName).CreateInstance(classname);  
        }
 
    }

这个工厂是由简单工厂进化而来，虽然switch和if是程序里的好东西，但是应对变化上，却显得老态龙钟。反射技术却可以很好地解决他们难以应对变化，难以维护，对修改开放的诟病。

 

小结

简单工厂到工厂方法，再到抽象工厂，是以灵活变化为主线逐步改善。不过在获得应对变化能力的同时，却以工作量大，效率为代价。所以运用哪种模式，还要根据具体情景，并不是简单工厂无用武之地，并不是运用抽象工厂就是最优。