在设计模式当中有三大工厂，分别是 简单工厂、抽象工厂、工厂方法 这三种创建实例的设计模式，这里先从简单工厂将其，从名字就可以看出这是这三种工厂模式当中最为简单的一种实现。
简单工厂一般由以下几个对象组成：
| 对象 | 作用 |
|---|---|
| 工厂类 | 负责创建产品 |
| 抽象产品类 | 工厂创建出来的产品抽象 |
| 具体产品类 | 继承自抽象产品类，具体的产品功能 |
那么我们为什么不直接 new 一个对象来执行操作呢？如果有以下代码:
我要评论public class BusinessClass
{
public void Process()
{
Car _car = new Car();
_car.Run();
}
}
这么写的话，一旦我们业务逻辑发生变化，我不想创建 Car 对象了，我想创建一个 AirPlane 对象，他也具有 Run 方法，这个时候这种写法就很尴尬了，我需要在后面加一个 AirPlane air = new AirPlane() 然后再 Run。
而工厂模式则将创建与使用分离开来，用户不用关心怎么创建的，只需要告诉工厂你需要哪种类型的对象，我给你创建好，你直接调用即可。乍一看来没有什么改变，但之前直接 new 对象的方式则造成 BusinessClass 对于 Car 等对象造成了一种依赖关系。
换句话说，如果按照上面那种方式书写，BusinessClass 则是依赖于 Car 对象的，而简单工厂则是降低对象之间的耦合度(依赖)的。
在上面的例子中，我们要封装他们的改变，他们之间改变的地方在于实例的创建，那么我们封装之后就由工厂来进行创建，便有以下代码：
抽象产品类：
public abstract class Product
{
void Run();
}
再有一个工厂类:
public static class Factory
{
public static Product CreateInstance(string type)
{
switch(type)
{
case "Car":
return new Car();
case "AirPlane":
return new AirPlane();
default:
return null;
}
}
}
有了工厂类，我们再来定义两个具体的实现类:
public class Car : Product
{
public override void Run()
{
Console.WriteLine("这是汽车");
}
}
public class AirPlane : Product
{
public override void Run()
{
Console.WriteLine("这是飞机");
}
}
之后我们再改一下刚才的 BusinessClass:
public class BusinessClass
{
public void Process()
{
Product car = Factory.CreateInstance("Car");
car.Run();
Product air = Factory.CreateInstance("AirPlane");
air.Run();
}
}
这里其实我们也察觉了，如果我们每增加一个具体的产品，那么我们的工厂方法逻辑也会越来越臃肿，而且工厂类一点不能正常运行，就
会造成灾难性的后果。
简单工厂仅适用于工厂类负责创建的对象，较少的话对于工厂类的逻辑也不会太复杂。而且用户仅需要知道传入工厂类的参数即可创建对象，用户不需要具体的创建过程。
如对本文有疑问， 点击进行留言回复！！
荐 厉害了！阿里P8架构师用4大技术文档带你深入解读爆火的中台战略
FlowableException: Error initialising dmn data model报错问题
网友评论