简单工厂模式

概念:      

       简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。

UML类图:

         分析一下，简单工厂的角色有，工厂角色(Creator)，抽象产品角色(IProduct)，以及具体产品角色(Product_A，Product_B)。

         “工厂类”是根据客户端传入的参数，动态地决定创建哪个“具体产品类”（而这些个“具体产品类”又继承至一个父类或接口），所以简单工厂模式属于创建型模式。

代码实现：

         我想以生产汽车为例子。

         首先我要有汽车类（这个可以是类，也可以是接口，抽象类应该也是可以的），然后为了简化问题，这个汽车类只有两种汽车，奔驰和宝马。而且为了简化问题，这些类都只有一个简单的方法。然后就是一个工厂类，这个工厂类有一个方法就是创建汽车。

UML图如下

         具体代码如下：

 

namespace SimplyCarFactory

{

    class Program

    {

        static void Main(string[] args)

        {

            //类都写完了，最后的客户端,CarFactory的静态创建方法的CreateCar的返回类型是ICar，所以

            ICar bmw = CarFactory.CreateCar("宝马");

            bmw.Show();

 

            ICar benz = CarFactory.CreateCar("奔驰");

            benz.Show();

        }

    }

    //首先是抽象产品角色，汽车接口

    interface ICar

    {

        void Show();

    }

    //然后是两个具体产品角色，宝马和奔驰,他们都要实现ICar接口

    class BMW:ICar

    {

        public void Show()

        {

            //内容很简单，只是输出一句话

            Console.WriteLine("一辆宝马诞生了！！！");

        }

    }

    //Benz类

    class Benz:ICar

    {

        public void Show()

        {

            Console.WriteLine("我是一辆奔驰！！！");

        }

    }

    //然后就是工厂角色，汽车工厂

    class CarFactory

    {

        public static ICar CreateCar(String carType)

        { 

           //里面,根据输入的carType,来决定生产哪个汽车

           //switch case语句。

            ICar car = null;

            switch (carType)

            { 

                case "宝马":

                    car = new BMW(); 

                    break;

                case "奔驰":

                    car = new Benz();

                    break;

            }

            return car;

        }

    }

}

运行结果：

         可以看出以上代码非常简单，简单工厂是非常常用的设计模式，但是他的缺点是，如果我需要再添加一种汽车，比如奥迪。那么增加一个奥迪汽车类这是可以的，但是需要修改CarFactroy的CreateCar方法，在switch…case中添加一条case语句，这就违背了开放-封闭原则。

         最后，觉得百度百科上的简单工厂模式的优缺点总结的挺好的，就拿来供自己和大家看看。

优点

        通过使用工厂类，外界可以从直接创建具体产品对象的尴尬局面摆脱出来，仅仅需要负责”消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。

缺点

       由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。

       当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；

       这些缺点在工厂方法模式中得到了一定的克服。

使用场景

       工厂类负责创建的对象比较少;

       客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心；

      由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。