工厂模式

工厂模式理论我不长篇大论了。其核心功能是根据“需求”生产“产品”，设计模式的核心是解耦。工厂模式就是为了解耦“需求”和“产品”，但是别忘了，工厂模式工厂模式，还有一个重要元素，就是“工厂”，所以工厂模式的核心思想，就是解耦“需求”“工厂”和“产品”。

 

工厂模式，实际上也会根据业务情景不同会有不同的实现方式。一般分为3种。简单工厂，工厂和抽象工厂。

关键点：

一、三种工厂的实现是越来越复杂的

二、简单工厂通过构造时传入的标识来生产产品，不同产品都在同一个工厂中生产，这种判断会随着产品的增加而增加，给扩展和维护带来麻烦

三、工厂模式无法解决产品族和产品等级结构的问题

四、抽象工厂模式中，一个工厂生产多个产品，它们是一个产品族，不同的产品族的产品派生于不同的抽象产品（或产品接口）。

五、用哪种工厂模式，取决于业务需求，不要认为简单工厂是用switch case就觉得一无是处，也不要觉得抽象工厂比较高大上就到处套。要根据三种工厂模式的特质，来确定使用哪种解决问题。

简单工厂

        int prodNo;
        public SimpleFactory(int prodNo) //构造工厂时告知工厂产品标识
        {
            this.prodNo = prodNo;
        }
 
        public IProduct GetProduct()
        {
            switch (prodNo) //根据产品标识生产产品
            {
                default:
                    return new ProductA();
                case 1:
                    return new ProductA();
                case 2:
                    return new ProductB();
            }
 
         }
 
 
    }
 
    //产品A
    class ProductA: IProduct 
    {
        //产品属性
        //......
    }
 
    //产品B
    class ProductB : IProduct
    {
        //产品属性
        //......
    }
    //产品接口
    interface IProduct
    {
        //产品方法
        //......
    }        

那么大家看看这段简单工厂的例子，如果我现在问，这个会有什么问题，该如何回答呢？提示一下，如果说来了一个需求，增加一个产品C，该如何办？没错，简单工厂的问题就在于swich case（或者if else)。每当新增一种产品时，你都需要去维护工厂中的判断语句，造成的后果就是可能这个工厂类会非常非常长，各种判断全部挤在一起，给扩展和维护带来很多麻烦。说白了，你的产品和工厂还是没有完全解耦，绑定在一起的。所以，我们得到了第二个结论：简单工厂通过构造时传入的标识来生产产品，不同产品都在同一个工厂中生产，这种判断会随着产品的增加而增加，给扩展和维护带来麻烦。那么，如何解决这个问题呢？

你猜对了，工厂模式可以解决这个问题：

 

工厂模式

    interface IFactory //工厂接口
    {
        IProduct GetProduct();
    }
 
    //A工厂类
    public class FactoryA: IFactory
    {
        IProduct productA;
        public FactoryA()
        {
            this.productA = new ProductA();
        }
 
        public IProduct GetProduct() //A工厂生产A产品
        {
            return this.productA;
        }
    }
 
    //B工厂类
    public class FactoryB : IFactory
    {
        IProduct productB;
        public FactoryB()
        {
            this.productB = new ProductB();
        }
 
        public IProduct GetProduct() //B工厂生产B产品
        {
            return this.productB;
        }
    }
 
    //产品接口
    public interface IProduct
    {
        //产品方法
        //......
    }
 
    //产品A
    public class ProductA : IProduct
    {
        //产品属性
        //......
    }
 
    //产品B
    public class ProductB : IProduct
    {
        //产品属性
        //......
    }

仔细观察这段代码，在工厂模式中，已经将工厂类分开，不再将所有产品在同一工厂中生产，这样就解决了简单工厂中不停的switch case的问题。如果说来了一个C产品，那么我们只需要写一个C工厂和C产品，在调用时用C工厂生产C产品即可，A和B工厂和产品完全不受影响。OK，优化说完了，但是还是有问题。

 

问题在哪里呢？当业务需求是需要生产产品族的时候，工厂就不再适合了。举个栗子：我想生产三星的洗衣机和格力的洗衣机，两个都是洗衣机，但是品牌不同，这个叫产品等级结构。最近格力的产品好卖，我想去生产格力的产品，不管是洗衣机还是冰箱都可以，只要是格力的就行，这个叫做产品族。而工厂模式无法解决产品族和产品等级结构的问题。这就要用到抽象工厂模式了。

 

抽象工厂

        //工厂接口，即抽象工厂
        interface IFactory
        {
            IFridge CreateFridge();
            IAirCondition CreateAirCondition();
        }
 
 
        //三星的工厂，生产三星的产品族
        public class SamsungFactory : IFactory
        {
  
            public IAirCondition CreateAirCondition() 
            {
                return new SamsungAirCondition(); //三星的工厂生产三星的空调
              
            }
 
            public IFridge CreateFridge()
            {
                return new SamsungFridge(); //三星的工厂生产三星的冰箱
            }
        }
 
        //格力的工厂，生产格力的产品族
 
        public class GreeFactry : IFactory
        {
            public IAirCondition CreateAirCondition()
            {
                return new GreeAirCondition(); //格力的工厂生产格力的空调
            }
 
            public IFridge CreateFridge()
            {
                return new GreeFridge(); //格力的工厂生产格力的冰箱
            }
        }
 
        //冰箱产品接口
        public interface IFridge
        {
            //冰箱产品接口
            //冰箱的action
        }
 
        //空调接口
        public interface IAirCondition
        {
            //空调产品接口
            //空调的action
        }
 
        //三星的冰箱
        public class SamsungFridge: IFridge
        {
           //三星冰箱的action和property
        }
        //格力的冰箱
        public class GreeFridge : IFridge
        {
             //格力冰箱的action和property
        }
 
        //三星的空调
        public class SamsungAirCondition : IAirCondition
        {
           //三星空调的action和property
        }
        //格力的空调
        public class GreeAirCondition : IAirCondition
        {
            //格力空调的action和property
        }

 

我们可以看到，三星这个工厂里面产三星空调和三星冰箱，这是一个产品族，而三星冰箱也是冰箱啊，所以它派生于冰箱这个产品。

在上面的代码中，都使用了接口来表达抽象工厂或者抽象产品，那么可以用抽象类吗？

从功能上说，完全可以，甚至可以用接口来定义行为，用抽象类来抽象属性。抽象类更加偏向于属性的抽象，而用接口更加偏向行为的规范与统一。使用接口有更好的可扩展性和可维护性，更加灵活实现松散耦合，所以编程原则中有一条是针对接口编程而不是针对类编程。