设计模式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模式共同组合来应对“对象创建”的需求变化。

巴特西

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

最新文章

热门文章