设计模式深入学习-抽象工厂模式

   今天我们来聊下抽象工厂模式。首先在程序设计的时候，我们最关心的是怎么解决需求经常变动的情况下如何去设计程序，来解决各个对象相互之间的耦合性的分离。我们在编写代码的时候，首先会经常New 很多新对象，比如创建一个Apple对象Apple apple=new Apple();我们新建一个 苹果对象 而New就会实现依赖，比如我们另外要新建一个香蕉对象Banana banana =new Banana()；那问题就出现了，New 实现依赖，不能应对“具体实例化类型”的变化。而我们的解决思路就是要把这些变化点找出来，封装起来，让客户程序调用的时候可以更方便的实现和扩展程序。变化点在“对象创建”，因此就封装“对象创建”，那么我们可以使用面向接口编程--依赖接口，而非依赖实现的方法来尝试解决问题。我们来看一段代码，类库实现：

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

//客户程序实现类
     Road road =
     RoadFactory.CreateRoad();

          上面一段是类库实现，就是我们需要经常改动的实现类，而下面一段是客户程序调用类，这一段一般来说是稳定的，改动比较小的。 然后我们继续扩展下去，创建一系列相互依赖的对象 ，我们先假设我们在构建一个游戏场景，我们需要道路，房屋，地道，丛林。。。等等对象。

//类库
public 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();
 
        Tunnel tunnel =
        RoadFactory.CreateTunnel();
 
        Jungle jungle =
        RoadFactory.CreateJungle();

   我们可以看到，代码里面声明了道路，房屋，地道，丛林。 如果我们的道路或者其中一个对象需要发生变化，那就只去修改道路这个类的具体实现就可以了，但是如果说新产生了新的道路，比如不同风格的道路，比如需要一个古典的道路，又或者是一个新的科技风格的道路，那我们需要做的就是 新做一个Road2 Road3等新的道路对象。让客户程序实现类还是需要重新Road road =RoadFactory.CreateRoad2();Road road =RoadFactory.CreateRoad3();改变。在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时，由于需求的变化，往往存在更多系列的对象的创建工作。现在我们尝试提供一个接口，让该接口负责一系列“相关或者相互依赖的对象”，无需指定他们具体的类。我们先来看一张架构图：  

   图中可以看到，左边那块是类库实现，右边的是客户类，ProductA1 A2代表这道路，房屋等。而ProductB1 B2 就代表着其他风格的道路，房屋。然后我们使用抽象接口方式重新封装一遍，使用抽象工厂模式来实现：

//抽象类
public class ModernRoad : Road { }//新风格道路
public class ModernBuilding : Building { } //新风格房屋
public class ModernTunnel : Tunnel { } //新风格地道
public class ModernJungle : Jungle { } //新风格丛林
 
//抽象工厂
public  abstract 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
{
    private FacilitiesFactory _ff;
    private Road road;
    private Building building;
    private Tunnel tunnel;
    private Jungle jungle;
 
    public GameManager(FacilitiesFactory ff)
    {
        _ff = ff;
    }
 
    public void BuildGameFacilities()
    {
        road = _ff.CreateRoad();
        building = _ff.CreateBuilding();
        tunnel = _ff.CreateTunnel();
        jungle = _ff.CreateJungle();
    }
 
    public void Run()
    {
        road.AAA();
        building.BBB(road);
        tunnel.CCC();
        jungle.DDD(tunnel);
    }
  
}
 
class APP
{
    public static void Main()
    {
        GameManager g=new GameManager(new ModernFacilitiesFactory);
 
        g.BuildGameFacilities();
        g.Run();
    }
}

   我们可以在代码中看到，如果我们想要一个科幻类风格的道路，房屋，地道丛林等，就声明好一些继承自FacilitiesFactory 的新Class ，然后在声明一些继承自Road Building等参数的新对象，而在GameManager 客户程序类中我们就无需修改参数，只需要在App类中Main函数中 新new一个新风格的这个场景即可GameManager g=new GameManager(new ModernFacilitiesFactory);比如我们这时候又想要一个古典风格的场景，包括道路，房屋，地道丛林等，那我们就重新在制作一个新的ClassFacilitiesFactory以及ClassRoad ClassBuilding ClassTunnel ClassJungle等参数。我们可以看到 一个简单又实用的抽象工厂模式就设计好了。最后我们来说下 抽象工厂模式设计的几个要点：        
    如果没有应对“多系列对象构建”的需求变化，则没有必要使用抽象工厂模式，这时候使用简单的静态工厂完全可以。
   “系列对象”指的是这些对象之间有互相依赖，或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖
    抽象工厂模式主要在于应对“新系列”的需求变动。其缺点在于难以应付“新对象”的需求变动。
    抽象工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化 。
    如果这几段话没有看明白的话，我来简单讲解几句，比如我们之前说的 道路，房屋，地道，丛林 这几个对象设计中，除了道路需要有很多种不同的类型，而房屋，地道，丛林是基本不用变动的，那么 抽象工厂模式不适合这样的设计，使用我们前边说的普通的静态工厂就可以了。但如果整套场景会有几个不同的风格需要变换，那么抽象工厂模式就非常适合处理这样的变动。
    这篇文章写的代码有点不全，主要是几个底层的接口类没写，大家主要了解这个工厂模式的设计，底层代码补全个名字的类就好了。