设计模式02： Abstract Factory 抽象工厂（创建型模式）

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

常见的对象创建方法：
    //创建一个Road对象
    Road road=new Road();
    
new的问题：
    -实现依赖，不能应对“具体实例化类型”的变化
    
解决思路：
    -封装变化点——那里变化，封装那里
    -潜台词：如果没有变化，当然不需要额外的封装
    
工厂模式的缘起
    变化点在“对象创建”，因此就封装“对象创建”
    面向接口编程——依赖接口，而非依赖实现
    最简单的解决方法：
    //类库

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

    客户程序调用：
    //创建一个Road对象
    Road road = RoadFactory.CreateRoad();
    
    若果Road是抽象类

    class RoadFactory{
        public static Road CreateRoad()
        {
            return new WaterRoad();//WaterRoad继承自Road
        }
    }

    客户程序调用：
    Road road = RoadFactory.CreateRoad();
    

创建一系列相互依赖的对象
我们需要构建“道路”、“房屋”、“地道”、“丛林”……等对象
他们之间都是有交互的

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();
    }
    
}

客户程序调用：
    Road road = RoadFactory.CreateRoad();
    Building building=RoadFactory.CreateBuilding();
    ……

简单工厂的问题：
    -不能应对“不同系统对象”的变化，比如不同风格的游戏场景——对应不同风格的道路、房屋、地道……

如何解决：
    -使用面向对象的技术来“封装”变化点
    
动机（Motivation）
在软件系统中，经常面临着“一系列相互依赖的对象”（不是对象本身的变化）的创建工作；同时，由于需求变化，往往存在更多系列对象的创建工作。
如何应对这种变化？如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列对象创建工作”的紧耦合？

“紧耦合”本身没有什么问题，关键是变化，不如没有变化就不需要解耦和了。

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

演示代码：

//道路
public abstract class Road
{

}
//房屋
public abstract class Building
{

}
//地道
public abstract class Tunnel
{

}
//丛林
public abstract class Jungle
{

}

//道路
public abstract class ModernRoad:Road
{

}
//房屋
public abstract class ModernBuilding:Building
{

}
//地道
public abstract class ModernTunnel:Tunnel
{

}
//丛林
public abstract class ModernJungle:Jungle
{

}

abstract class FacilitiesFactory
{
    public abstract Road CreateRoad();
    public abstract Building CreateBuilding();
    public abstract Tunnel CreateTunnel();
    public abstract Jungle CreateJungle();
}

public class ModernFacilitiesFactory:FacilitiesFactory
{
    public override Road CreateRoad()
    {
        return new ModernRoad();
    }
    public override Building CreateBuilding()
    {
        return new ModernBuilding();
    }
    public override Tunnel CreateTunnel()
    {
        return new ModernTunnel();
    }
    public override Jungle CreateJungle()
    {
        return new ModernJungle();
    }
}

//客户程序
class GameManager//因为业务原因这个地方原来是非常复杂的，作为变化点封装后就不需要改变了
{
    FacilitiesFactory facilitiesFactory;
    Road road;
    Building building;
    Tunnel tunnel;
    Jungle jungle;


    public Gamemanager(FacilitiesFactory facilitiesFactory)
    {
        this.facilitiesFactory=facilitiesFactory;
    }
    
    public void BuildGameFacilities()
    {
        road=facilitiesFactory.CreateRoad();
        building = facilitiesFactory.CreateBuilding();
        tunnel=facilitiesFactory.CreateTunnel();
        jungle=facilitiesFactory.CreateJungle();
        
    }
    
    public void Run()
    {
        road.AAA();
        building.BBB(road);
        tunnel.CCC();
        jungle.DDD(tunnel);
    }
}

class App
{
    public sttic void Main()
    {
        GameManager g=new GameManager(new ModernFacilitiesFactory())
        //若要定义古典风格的，就传ClassicalFacilitiesFactory，
        //ClassicalFacilitiesFactory和ModernFacilitiesFactory类相似，这里就不写了
        //GameManager g=new GameManager(new ClassicalFacilitiesFactory())
        g.BuildGameFacilities();
        g.Run();
    }
}

Abstract Factory模式的几个要点：
若果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的静态工厂完全可以。
“系列对象”指的是这些对象之间有相互依赖、或者作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖。
Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点是难以应对“新对象”的需求变动。
Abstract Factory模式经常和Factory Method模式共同组合来应对“对象创建”的需求变化。