C# 设计模式学习三 Abstract Factory 抽象工厂(概念)

Abstract Factory 抽象工厂（创建型模式）

一，new的问题

① 创建型模式主要解决的就是一个new的问题

常规的对象创建方法 Road road = new Road()；

② new的问题 模式设计很多是由于new的方式引起的，
而抽象工厂要讨论的问题就是，常规的方式依赖于new，不能应对“具体实例化类型”的变化

③ 对应的解决思路：
封装变化点 -> 那里变化，那里封装（如果没有变化，当然不需要封装）

※封装变化点，设计模式很多就是要解决变化点的封装，找到变化点，并进行封装

二，工厂模式的缘起

①
既然变化点在于“对象创建”，因此就封装“对象创建”

面向接口编程，可以实现依赖于接口，而非依赖于实现

最近单的方法
class Road { }

class RoadFactory
{
public static Road CreateRoad() { return new Road(); }
}

class Program
{
static void Main(string[] args)
{
RoadFactory roadFactory = new RoadFactory();
Road road = RoadFactory.CreateRoad();
}
}

②
当我们想改变 return new Road();的内容的时候只需要在RoadFactory工厂类中进行改变
比如我们想new 一个新的道路类型，比如泥路，水路，航路，绿化过的路等等各种类型
假设一个新类型WaterRoad水路 就要改成return new WaterRoad();
再隐身如果需要创造更多类型的时候，就需要应对更为复杂的变化

比如我们可以这样改变RoadFactory
class Road { }
class Building { } //建筑
class Tunnel { } //地道
class Jungle { } //丛林

class RoadFactory
{
public static Road CreateRoad() { return new Road(); }
public static Building CreateBuilding() { return new Building(); }
public static Tunnel CreateTunnel() { return new Tunnel(); }
public static Jungle CreateJungle() { return new Jungle(); }
}

class Program
{
static void Main(string[] args)
{
Road road = RoadFactory.CreateRoad();
Building building = RoadFactory.CreateBuilding();
}
}

③
问题：

用静态方法的方式实现工厂类，那么还是会有存在变化点的问题，程序相对来说不是稳定的
不能应对不同系列的变化，又不能为每一个系列创建工厂，比如BuildingFactory,TunnelFactory等，

三，创建工厂模式的动机

① 在软件系统中，经常面临“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，“往往存在更多系列对象的创建工作”。
比如不同风格的道路，地道，丛林等等... ...

② 问题 如果绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合。

※“”部分是重点

③ 意图：提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定他们具体的类。----《设计模式》GoF

四，该模式使用的注意事项

① 如果没有应对多系列对象构建的需求变化，则没有必要使用抽象工厂。简单的静态工厂完全可以。
（如果是稳定的几个类型，只是风格（系列）发生变化的话，那么就是适用于抽象工厂模式）

② 系列对象 指的是这些对象之间又相互依赖关系，或作用的关系，例如：游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖

③ 抽象工厂模式主要在于应对 有“新系列”的需求变动，其缺点在于难以应对“新对象”的需求变动

④ 抽象工厂模式经常和Factory Method(工厂方法)模式共同组合来应对“对象创建”的需求变化。