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