今天我们来聊下抽象工厂模式。首先在程序设计的时候,我们最关心的是怎么解决需求经常变动的情况下如何去设计程序,来解决各个对象相互之间的耦合性的分离。我们在编写代码的时候,首先会经常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();改变。在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作,同时,由于需求的变化,往往存在更多系列的对象的创建工作。现在我们尝试提供一个接口,让该接口负责一系列“相关或者相互依赖的对象”,无需指定他们具体的类。我们先来看一张架构图:
//抽象类
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等参数。我们可以看到 一个简单又实用的抽象工厂模式就设计好了。最后我们来说下 抽象工厂模式设计的几个要点: 如果没有应对“多系列对象构建”的需求变化,则没有必要使用抽象工厂模式,这时候使用简单的静态工厂完全可以。
“系列对象”指的是这些对象之间有互相依赖,或作用的关系,例如游戏开发场景中的“道路”与“房屋”的依赖,“道路”与“地道”的依赖
抽象工厂模式主要在于应对“新系列”的需求变动。其缺点在于难以应付“新对象”的需求变动。
抽象工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化 。
如果这几段话没有看明白的话,我来简单讲解几句,比如我们之前说的 道路,房屋,地道,丛林 这几个对象设计中,除了道路需要有很多种不同的类型,而房屋,地道,丛林是基本不用变动的,那么 抽象工厂模式不适合这样的设计,使用我们前边说的普通的静态工厂就可以了。但如果整套场景会有几个不同的风格需要变换,那么抽象工厂模式就非常适合处理这样的变动。
这篇文章写的代码有点不全,主要是几个底层的接口类没写,大家主要了解这个工厂模式的设计,底层代码补全个名字的类就好了。