创建型模式:抽像工厂模式(Abstract Factory)
2011-04-24 16:58
155 查看
创建型模式:抽像工厂模式(Abstract Factory)
1、new的问题
常规的对象创建方法:
// 创建一个Road对象
Road road = new Road();
new的问题:
-实现依赖,不能应对“具体实例化类型”的变化。
解决思路:
-封装变化点——哪里变化,封装哪里
-潜台词:如果没有变化,当然不需要额化的封装!
2、工厂模式的缘起
变化点在“对象创建”,因此就封装“对象创建”
面向接口编程——依赖接口,而非依赖实现
最简单的解决方法:
class RoadFactory{ // 类库
public static Road CreateRoad(){
return new Road();
// Road是个抽象类,返回一个特定的工厂
// return new WaterRoad();
}
}
// 客户程序:创建一个Road对象
Road road = roadFactory.CreateRoad();
3、假设一个游戏开发场景:
我们需要构造“道路”、“房屋”,“地道”、“丛林”等对象,我们需要建立一系列对象,这些对象相互依赖
Road road = roadFactory.CreateRoad();
...
Building building = roadFactory.CreateBuilding();
...
以上代码相对稳定
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(); // 创建丛林
}
}
纯静态的方法不好,上述代码如果需求改变,它可能是变化点
4、简单工厂的问题
不能应对“不同系列对象”的变化。比如有不同风格的,游戏场景——对应不同风格的道路、房屋、地道、丛林等
如何应对这种变化,如何解决: 使用面向对象的技术来“封装”变化点。
5、动机(Motivation)
在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时,由于需求的变化,往往存在更多系列对象的创建工作。
如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避名免客户程序和这种“多系列具体对象创建工作”的紧耦合?
6、意图(Intent)
提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类。
7、具体实现
//道路
public abstract class Road
{
}
//房屋
public abstract class Building
{
}
//地道
public abstract class Tunnel
{
}
//丛林
public abstract class Jungle
{
}
// 第一种风格的设施:现代风格
//道路
public class ModernRoad : Road
{
}
//房屋
public class ModernBuilding : Building
{
}
//地道
public class ModernTunnel : Tunnel
{
}
//丛林
public 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();
}
}
客户程序:整个诊赖于抽象工厂,没有依赖具体的实现,我们的目的是需要GameManager类稳定下来,不需要变动。
class GameManager
{
private FacilitiesFactory facilitiesFactory;
private Road road;
private Building building;
private Tunnel tunnel;
private Jungle jungle;
public GameManager(FacilitiesFactory facilitiesFactory)
{
this.facilitiesFactory = facilitiesFactory;
}
public void BuildGameGameFacilities()
{
road = facilitiesFactory.CreateRoad();
building = facilitiesFactory.CreateBuilding();
tunnel = facilitiesFactory.CreateTunnel();
jungle = facilitiesFactory.CreateJungle();
//如果设施变化剧烈,这里抽象工厂就是误用,变化剧烈的应该是这些设施的风格
}
public void Run()
{
road.A();
building.B(road);
tungle.C();
jungle.D();
}
}
class App
{
public static void Main()
{
//只需改这里就行,需要什么风格就new什么风格,这里运行现代风格new ModernFacilitiesFactory()
FacilitiesFactory facilitiesFactory = new ModernFacilitiesFactory()
//可以从web.config文件中设置相关,利用.net的反射得到特定风格的工厂
GameManger gm = new GameManager(facilitiesFactory);
gm.BuildGameGameFacilities();
gm.Run();
}
}
8、Abstract Factory模式的几个要点
1)如果没有应对“多系列对象构建”的需求变化,则没有必要使用抽像工厂模式,这时候使用简单的静态工厂完全可以。
2)“系列对象”指的是这些对象之间有相互依赖、或作用的关系,例如游戏开发场景中的“道路”的依赖,“道路”与“地道”的依赖。
3)抽像工厂模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。
4)抽像工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化。
1、new的问题
常规的对象创建方法:
// 创建一个Road对象
Road road = new Road();
new的问题:
-实现依赖,不能应对“具体实例化类型”的变化。
解决思路:
-封装变化点——哪里变化,封装哪里
-潜台词:如果没有变化,当然不需要额化的封装!
2、工厂模式的缘起
变化点在“对象创建”,因此就封装“对象创建”
面向接口编程——依赖接口,而非依赖实现
最简单的解决方法:
class RoadFactory{ // 类库
public static Road CreateRoad(){
return new Road();
// Road是个抽象类,返回一个特定的工厂
// return new WaterRoad();
}
}
// 客户程序:创建一个Road对象
Road road = roadFactory.CreateRoad();
3、假设一个游戏开发场景:
我们需要构造“道路”、“房屋”,“地道”、“丛林”等对象,我们需要建立一系列对象,这些对象相互依赖
Road road = roadFactory.CreateRoad();
...
Building building = roadFactory.CreateBuilding();
...
以上代码相对稳定
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(); // 创建丛林
}
}
纯静态的方法不好,上述代码如果需求改变,它可能是变化点
4、简单工厂的问题
不能应对“不同系列对象”的变化。比如有不同风格的,游戏场景——对应不同风格的道路、房屋、地道、丛林等
如何应对这种变化,如何解决: 使用面向对象的技术来“封装”变化点。
5、动机(Motivation)
在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;同时,由于需求的变化,往往存在更多系列对象的创建工作。
如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避名免客户程序和这种“多系列具体对象创建工作”的紧耦合?
6、意图(Intent)
提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类。
7、具体实现
//道路
public abstract class Road
{
}
//房屋
public abstract class Building
{
}
//地道
public abstract class Tunnel
{
}
//丛林
public abstract class Jungle
{
}
// 第一种风格的设施:现代风格
//道路
public class ModernRoad : Road
{
}
//房屋
public class ModernBuilding : Building
{
}
//地道
public class ModernTunnel : Tunnel
{
}
//丛林
public 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();
}
}
客户程序:整个诊赖于抽象工厂,没有依赖具体的实现,我们的目的是需要GameManager类稳定下来,不需要变动。
class GameManager
{
private FacilitiesFactory facilitiesFactory;
private Road road;
private Building building;
private Tunnel tunnel;
private Jungle jungle;
public GameManager(FacilitiesFactory facilitiesFactory)
{
this.facilitiesFactory = facilitiesFactory;
}
public void BuildGameGameFacilities()
{
road = facilitiesFactory.CreateRoad();
building = facilitiesFactory.CreateBuilding();
tunnel = facilitiesFactory.CreateTunnel();
jungle = facilitiesFactory.CreateJungle();
//如果设施变化剧烈,这里抽象工厂就是误用,变化剧烈的应该是这些设施的风格
}
public void Run()
{
road.A();
building.B(road);
tungle.C();
jungle.D();
}
}
class App
{
public static void Main()
{
//只需改这里就行,需要什么风格就new什么风格,这里运行现代风格new ModernFacilitiesFactory()
FacilitiesFactory facilitiesFactory = new ModernFacilitiesFactory()
//可以从web.config文件中设置相关,利用.net的反射得到特定风格的工厂
GameManger gm = new GameManager(facilitiesFactory);
gm.BuildGameGameFacilities();
gm.Run();
}
}
8、Abstract Factory模式的几个要点
1)如果没有应对“多系列对象构建”的需求变化,则没有必要使用抽像工厂模式,这时候使用简单的静态工厂完全可以。
2)“系列对象”指的是这些对象之间有相互依赖、或作用的关系,例如游戏开发场景中的“道路”的依赖,“道路”与“地道”的依赖。
3)抽像工厂模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。
4)抽像工厂模式经常和工厂方法模式共同组合来应对“对象创建”的需求变化。
相关文章推荐
- 设计模式-创建型模式:简单工厂SimpleFactory
- 设计模式-创建型模式:工厂方法FactoryMethod
- 创建型模式01:简单工厂模式、工厂方法模式、抽象工厂模式
- 2.Abstract Factory 抽象工厂(创建型模式)之简单工厂
- 设计模式_创建型模式——工厂方法
- 创建型-工厂模式(simple factory)
- 创建型模式之工厂方法
- js创建型设计模式--简单工厂模式
- [设计模式-创建型]工厂方法(Factory Method)
- 一起来学设计模式-----创建型模式之简单工厂
- JAVA设计模式(24):创建型-工厂模式【工厂方法模式】(Factory Method)
- 工厂模式,常用的设计模式(创建型模式)及分类
- 创建型模式之工厂模式实现
- 创建型模式之 工厂、简单工厂、抽象工厂 简单图析和代码分析 笔记
- JAVA设计模式(01_1):创建型-工厂模式【工厂方法模式】(Factory Method)
- 【转】设计模式——创建型设计模式总结(简单工厂、普通工厂、抽象工厂、建造者、原型和单例)
- 创建型模式:工厂模式(简单工厂模式,抽象工厂模式,工厂模式)
- 设计模式之简单工厂(创建型模式)
- JAVA设计模式(01):创建型-工厂模式【工厂方法模式】(Factory Method)
- 创建型设计模式(简单工厂,工厂,抽象工厂与单例模式