【C# 设计模式-简单工厂模式 】

网上有很多关于类似工厂模式的博客，大都说明的很详细，这里我结合在项目中的体会简单说一下！

介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是一个工厂方法模式的一个引导。

简单工厂模式结构图：

角色：

工厂（Creator）角色
简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
抽象产品（Product）角色
简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。
具体产品（Concrete Product）角色
是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。

引入实际情况：

如果有一个住户管理系统，里面的住户类型是可变的，每一种租户类型的租金计算公式都存在差异

例如：A类型的住户租金额=天数*单价+绩效*0.005

         B类型的住户租金额=月份*(每月价格+performance*0.001)

分析：

1. 商店存在共有的计算方法，这是实体商店的行为，然而他们的行为的方式不一样，所有我们抽象商店类，代码>>>

using System;using System.Collections.Generic;using System.Linq;using System.Text;namespace SimpleFactory.App.IFactroy{        public interface Ishop    {        double Getrent(int days, double dayprice, double performance);    }}

2.在抽象了商店之后，我们要对创建具体产品类，这里就是具体的类型商店，里面实现该商店的行为方法。

创建A类型的商店

using SimpleFactory.App.IFactroy;using System;using System.Collections.Generic;using System.Linq;using System.Text;namespace SimpleFactory.App.product{    //A类型的商店的创建    public class Ashop:Ishop    {        /// <summary>        /// /// A类型商店租金额，天数*单价+绩效*0.005        /// </summary>        /// <param name="days">天数</param>        /// <param name="dayprice">每天单价</param>        /// <param name="performance">日平均绩效</param>        /// <returns></returns>        public double Getrent(int days, double dayprice, double performance)        {            Console.WriteLine("A商店的租金算法");            return days * dayprice + performance * 0.01;        }    }}

创建B类型的商店

using SimpleFactory.App.IFactroy;using System;using System.Collections.Generic;using System.Linq;using System.Text;namespace SimpleFactory.App.product{    /// <summary>    /// B类型的商店的创建    /// </summary>    public class Bshop:Ishop    {                /// <summary>        /// B类型商店的租金=月份*(每月价格+performance*0.001)        /// </summary>        /// <param name="month">月数</param>        /// <param name="monthprice">月单价</param>        /// <param name="performance">月平均绩效</param>        /// <returns></returns>        public double Getrent(int month, double monthprice, double performance)        {            Console.WriteLine("B商店的租金算法");            return month * (monthprice + performance * 0.001);        }    }}

3. 在创建号类型商店并实现方法后，思考在什么情况下如何创建那种对象，于是简单工厂模式中最核心的部分：工厂类出来了

using SimpleFactory.App.IFactroy;using SimpleFactory.App.product;using System;using System.Collections.Generic;using System.Linq;using System.Text;namespace SimpleFactory.App.factoryMethod{    public class factorymethod    {        public Ishop CreateShow(string show)        {            switch (show.Trim().ToLower())            {                case"ashop":                    return new Ashop();                case "bshop":                    return new Ashop();                default:                    throw new Exception("该商店不存在");            }        }    }}

4.     然后就根据当前的商店类型进行判断，该类型的商店应该进行哪一种算法：

using SimpleFactory.App.factoryMethod;using SimpleFactory.App.IFactroy;using System;using System.Collections.Generic;using System.Linq;using System.Text;namespace SimpleFactory.App{    class Program    {        static void Main(string[] args)        {            Ishop As;            factorymethod afm = new factorymethod();            As = afm.CreateShow("ashop"); //a 类型的某商店            double total = As.Getrent(30, 300, 2000);     //30 天/100元  日平均绩效为2000            Console.WriteLine("该A类型商店的租金为：" + total);            Console.WriteLine("=============");            Ishop Bs;            factorymethod bfm = new factorymethod();            Bs = bfm.CreateShow("bshop"); //b 类型的某商店            total = Bs.Getrent(3, 3000, 60000);          //3 月/4000元  月平均绩效为60000            Console.WriteLine("该B类型商店的租金为：" + total);            Console.ReadKey();        }    }}

这样就通过简单工厂模式实现类对于当前商店的店铺租金应该进行那种算法的计算。

到这里我们实现了客户要求的两种类型商店的算法的需求，但是作为一种好的设计架构，还应该考虑到后面的需求变革，如果客户现在又

增加了C类型商店和D类型商店，它们的算法要求又不一样，这个时候我们就需要进行C，D类型商店的创建，并继承Ishop接口，实现里面的方法，

同时还得继续修改工厂类在switc中增加case进行捕捉创建相应的商店对象，一旦出现这样的情况，是不利于程序的扩展性和项目后期的维护性的。

优点：

• 简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过它，外界可以从直接创建具体产品对  象的尴尬局面中摆脱出来。
• 外界与具体类隔离开来，偶合性低。
• 明确区分了各自的职责和权力，有利于整个软件体系结构的优化。

缺点：

• 工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则 
• 虽然简单工厂模式能够适应一定的变化，但是它所能解决的问题是远远有限的。它所能创建的类只能是事先教考虑到的，如果需要添加新的类，则就需要改变工厂类了。

出现的上诉情况，应该如何解决，值得思考，将在下一个工厂方法模式中得到很好的解决。