概念:
简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。
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语句,这就违背了开放-封闭原则。
最后,觉得百度百科上的简单工厂模式的优缺点总结的挺好的,就拿来供自己和大家看看。
优点
通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责”消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的.明确了各自的职责和权利,有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑,违反了高内聚责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。
当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;
这些缺点在工厂方法模式中得到了一定的克服。
使用场景
工厂类负责创建的对象比较少;
客户只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心;
由于简单工厂很容易违反高内聚责任分配原则,因此一般只在很简单的情况下应用。