奇幻RPG(人物构造 与 Abstract Factory模式)

在前一节,我们介绍了Strategy模式,并使用此模式实现了一个根据角色的职业来分配技能的范例(实际也就是动态地为类分配方法)。作为一款奇幻RPG,有了职业,我们还应当可以为角色选择种族,比如说:人类(Human)、精灵(Elf)、矮人(Dwarf)、兽人(Orc)等等。而这四个种族又有着截然不同的外形,精灵皮肤灰白、有着长长的耳朵、没有体毛和胡须;矮人的皮肤与人类近似,但是身材矮小、通常留着浓密的胡子;兽人则有着绿色的皮肤和高大的身躯,并且面目丑陋。本文将讨论如何使用GOF的Abstract Factory抽象工厂来实现这样的角色外形设计。

面向实现的方式

简单起见,我们假设角色身体由三部分构成,分别是:头(Head)、身材(Stature)、皮肤(Skin)。那么对于人类的构造,我们的第一反应自然而然地想到:它应当由 HumanHead、HumanStature、HumanSkin三个类复合而成。对于精灵也是类似的设计,于是,我们实现了下面这样的设计(本文将仅以人类和精灵为例介绍):

抽象组成身体的实体类

我们发现这样做,每个角色与他的身体部件是牢牢绑定在一起的,每创建一个角色,我们都需要为它先行创建所有其复合的类(组成身体的实体类(Concret Class),比如HumanHead)。按照面向对象的思想,我们想到应该对这一过程进行封装,将创建角色部件这件事委派给其他的类来完成。观察上图,我们发现尽管角色不同,但它们都是由三个部分构成,所以,我们所能想到的实现这一过程的第一步,就是对组成身体的实体类进行抽象,我们定义三个接口:Head、Stature、Skin,代表身体的三个部分,并且让Human和Elf的实体类去实现这个接口:

观察上图,我们发现尽管定义了接口,但是如果角色Human和Elf仍然与接口的实体类关联,那么效果与面向实现完全相同。现在,是时候对设计做些改动,我们让Human和Elf与接口关联,而不是与接口的实现关联(OO思想:面向接口编程,而不是面向实现编程)。这一次,我们的设计变成下图:

一眼望去,我们发现的第一个问题就是:Human与Elf惊人地相似,再仔细看看,我们注意到它们除了名字不同其余的完全一样。我们不禁思考:有必要把两个完全一样的类起两个名字分别保存么?答案是没有必要,我们将它们合并成一个类,起名叫Race,设计再次变成下面这样:

创建工厂类

看到这里,我们可能会想:现在结构似乎已经很完善了,我们定义了接口来解决问题,也没有为不同的角色创建多个不同的类,而只要在Race的构造函数中为代表身体部件的变量赋不同的值,就可以创建不同种族的角色。好的,那么我们来看看如果要创建一个Human 代码需要如何编写:

Head head = new HumanHead();
Stature stature = new HumanStature();
Skin skin = new HumanSkin();
Race human = new Race(head, stature, skin);

而Race的构造函数是这样的:

public Race(head, stature, skin){
    this.head = head;
    this.stature = stature;
    this.skin = skin;
}

我们看到,仅仅创建一个类这样似乎太麻烦了,而且身体的部分类是角色的组成部分,为什么它们要先于角色创建呢?

这时候,我们想到如果有一个类可以专门负责创建身体部件这件事,当我们想要创建角色的时候,将这个类传递给Race的构造函数就可以了。我们管创建Human身体组成部分的类称作:HumanPartsFactory,创建Elf身体部分的类称作ElfPartsFacotry。那么它们应该是这样的:

现在,我们再要创建一个Human,代码变成了这样:

HumanPartsFactory humanFactory = new HumanPartsFactory();
Race Human = new Race(humanFactory);

相应的,我们的构造函数也需要改一改:

public Race(HumanPartsFactory humanFacotry){
    head = humanFactory.CreateHead();
    stature = humanFactory.CreateStature();
    skin = humanFactory.CreateSkin();
}

一切似乎都很好,直到我们需要创建一个Elf的时候... 我们发现Race的构造函数只能接受一个HumanPartsFactory类型的参数,为了传递ElfPartsFactory,我们将不得不再添加一个接受ElfPartsFactory类型的构造函数。这样显然不好,这一次,有了之前的经验,我们知道我们可以通过同样的方法来解决。

看到这里,你是否能够体会到一些“面向接口”编程的意味?注意到RacePartsFactory,它内部的方法返回的都是接口类型,而其实体子类的方法返回的都是接口的实体类。如果我们之前不声明那看似无用的接口,这里是无法实现的。

现在,我们再次修改Race的构造函数:

public Race(RacePartsFactory raceFacotry){
    head = raceFacotry.CreateHead();
    stature = raceFacotry.CreateStature();
    skin = raceFacotry.CreateSkin();
}

当我们需要一个Human的时候:

RacePartsFactory humanFactory = new HumanPartsFactory();
Race human = new Race(humanFactory);

当我们需要一个Elf的时候:

RacePartsFactory elfFactory = new ElfPartsFactory();
Race elf = new Race(elfFactory);

Abstract Factory设计模式

上面做的这些,使我们又完成了一个设计模式:Abstract Factory。它的正式定义是这样的:提供一个接口用于创建一系列相互关联或者相互依赖的对象,而不需要指定它们的实体类。

下面是本例中 Abstract Factory模式的最终图:

代码实现和测试

using System;
using System.Collections.Generic;
using System.Text;

namespace AbstractFactory {

// 定义构成身体部分的接口
    public interface IHead {  string name { get;} }
    public interface IStature {  string name { get;} }
    public interface ISkin {  string name { get;} }

// 组成 Human 的类
    public class HumanHead : IHead { public string name { get { return "Human Head"; } } }
    public class HumanStature : IStature { public string name { get { return "Human Stature"; } } }
    public class HumanSkin : ISkin { public string name { get { return "Human Skin"; } } }

// 组成 Elf 的类
   public class ElfHead : IHead { public string name { get { return "Elf Head"; } } }
    public class ElfStature : IStature { public string name { get { return "Elf Stature"; } } }
   public class ElfSkin : ISkin { public string name { get { return "Elf Skin"; } } }

// 定义工厂接口
    public interface IRacePartsFactory {
       IHead CreateHead();
       ISkin CreateSkin();
       IStature CreateStature();
    }

// 定义Human身体的工厂类
    public class HumanPartsFactory : IRacePartsFactory {
       public IHead CreateHead() {
           return new HumanHead();
       }
       public IStature CreateStature() {
           return new HumanStature();
       }
        public ISkin CreateSkin() {
           return new HumanSkin();
       }
    }

// 定义Elf身体的工厂类
    public class ElfPartsFactory : IRacePartsFactory {
       public IHead CreateHead() {
           return new ElfHead();
       }
       public IStature CreateStature() {
           return new ElfStature();
        }
       public ISkin CreateSkin() {
           return new ElfSkin();
       }
    }
    
    // 定义 Race 类
    public class Race {
       public IHead Head;    // 做示范用,所以没有构建属性
       public IStature Stature;
       public ISkin Skin;

public Race(IRacePartsFactory raceFactory) {
           Head = raceFactory.CreateHead();
           Stature = raceFactory.CreateStature();
           Skin = raceFactory.CreateSkin();
       }
    }

class Program {
       static void Main(string[] args) {
           // 创建一个 精灵(Elf)
           Race Elf = new Race(new ElfPartsFactory());
           Console.WriteLine(Elf.Head.name);
           Console.WriteLine(Elf.Stature.name);           
           Console.WriteLine(Elf.Skin.name);
       }
    }
}

总结

本文中我们一步步学习了Abstract Factory抽象工厂模式的实现。

我首先介绍了我们奇幻RPG所面临的一个问题:我们需要创建形态各异的角色。随后,我们通过面向实现的方式来完成了这一过程,并讨论了它的不足。随后,我们先通过接口的使用对种族进行了抽象。接着,我们由将创建角色组成部分类的过程进行了封装,将这一过程委派给了工厂类。最后,我们又对工厂类进行了抽象,最终实现了Abstract Factory工厂模式。

希望本文能给你带来帮助。

时间: 2024-10-18 07:52:01

奇幻RPG(人物构造 与 Abstract Factory模式)的相关文章

面向对象设计——抽象工厂(Abstract Factory)模式

定义 提供一个创建一系列相关或者相互依赖对象的接口,而无需指定它们具体的类.抽象工厂允许客户使用抽象的接口来创建一组相关的产品,而不需要知道或关心实际产出的具体产品是什么.这样一来,客户就能从具体的产品中被解耦. 适用场景 在以下情况可以使用Abstract Factory模式 一个系统要独立于它的产品的创建.组合和表示时 一个系统要由多个产品系列中的一个来配置时 当你要强调一系列相关的产品对象的设计以便进行联合使用时 当你提供一个产品类库,而只想显示它们的接口而不是实现时 UML图 抽象工厂模

设计模式(3)-对象创建型模式-Abstract Factory模式

1.对象创建型模式 1.3           Abstract Factory模式 1.3.1 需求 在下面情况能够使用Abstract Factory模式: ?  一个系统要独立于它的产品的创建.组合和表示时(这个需求和FactoryMethod类似). ?  一个系统要由多个产品系列中的一个来配置时(这个需求也和Factory Method类似). ?  当你要强调一系列相关的产品对象的设计以便进行联合使用时(这个需求表明一个工厂要创建多个相关的产品对象,是比FactoryMethod多的

简洁 Abstract Factory模式(3.1)

镇楼 在某些书中使用了二维图说明抽象工厂模式.非常好,可是yqj2065不喜欢他们的产品族/产品等级,改成品牌/产品类型. 抽象工厂模式(abstract factory pattern)较工厂方法模式强大之处.是一个工厂可以创建多个配套的产品. 日常生活中.抽象工厂模式比比皆是.比如服装厂能够生产配套的上衣/Tops.下装/Bottoms.电器公司如美的.海尔能够生产其品牌的冰箱.空调.电视机等. 抽象工厂模式的特点就是工厂接口中有两个以上的工厂方法. 例程 2-6 品牌公司 package

23设计模式(3):Abstract Factory模式

定义:要创建一组相关或依赖对象提供一个接口,而你并不需要指定其具体类别. 类型:创建一个类模型 类图: 抽象工厂模式与工厂方法模式的差别 抽象工厂模式是工厂方法模式的升级版本号,他用来创建一组相关或者相互依赖的对象.他与工厂方法模式的差别就在于.工厂方法模式针对的是一个产品等级结构:而抽象工厂模式则是针对的多个产品等级结构.在编程中.通常一个产品结构,表现为一个接口或者抽象类,也就是说.工厂方法模式提供的全部产品都是衍生自同一个接口或抽象类.而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类

说谎的简单工厂模式设计模式&工厂方法模式&Abstract Factory模式

工厂模式被分成三个:简单工厂模式,抽象工厂模式和工厂模式. 定义: 简单工厂模式:用一个单独的类来做创造实例的过程. 工厂模式:一个用于创建对象的接口.让子类决定实例化哪一个类,讲一个类的实例化 延迟到其子类. 抽象工厂模式:为创建一组相关或相互依赖的对象的类,而不指定详细类. 结构图: 这是简单工厂的结构图,从图中就非常好理解. 简单工厂的长处: 依据用户须要,new出须要的对象. 可是简单工厂弊端: 当新增加一个功能是.就要改动工厂. 这个时候,就须要工厂模式了. watermark/2/t

c++ 设计模式9 (Abstract Factory 抽象工厂模式)

5.2 抽象工厂模式 动机:在软件系统中,经常面临着"一系列相互依赖的对象"的创建工作:同时,由于需求的变化,往往存在更多系列对象的创建工作. 代码示例: 实现利用数据库的业务逻辑,支持多数据库(Sql,Oracle等),有连接.命令.读取等功能. 其中命令,连接功能之间有相互联系. 方法一(使用工厂方法): 每个功能类有一个创建的工厂,如IDBConnection与IDBConnectionFactory 1 //数据库访问有关的基类 2 class IDBConnection{ 3

抽象工厂(Abstract Factory)模式

一.抽象工厂(Abstract Factory)模式 抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态. 为了方便引进抽象工厂模式,引进一个新概念:产品族(Product Family).所谓产品族,是指位于不同产品等级结构,功能相关联的产品组成的家族.如图: 图中一共有四个产品族,分布于三个不同的产品等级结构中.只要指明一个产品所处的产品族以及它所属的等级结构,就可以唯一的确定这个产品. 引进抽象工厂模式 所谓抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产

设计模式可复用面向对象软件设计基础之对象创建型模式—ABSTRACT FACTORY( 抽象工厂)

意图 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类. 适用性 在以下情况可以使用 Abstract Factory模式 ? 一个系统要独立于它的产品的创建.组合和表示时. ? 一个系统要由多个产品系列中的一个来配置时. ? 当你要强调一系列相关的产品对象的设计以便进行联合使用时. ? 当你提供一个产品类库,而只想显示它们的接口而不是实现时. 结构 模式结构图如下所示: Creator: 声明一个创建抽象产品对象的操作接口. ConcreteCreator:(Concrete

再议工厂模式(Abstract Factory)和DIP的关系

大多数人说的工厂模式,应该是指GOF设计模式里面的Abstract Factory模式. 这是一种很常见又很有用的模式.它和DIP原则又有什么关系呢? DIP原则 DIP: Dependency inversion principle. DIP也就是依赖倒置原则,讲的是上层模块应该依赖于接口,具体类应该依赖于抽象接口(也就是被迫实现抽象接口).因为抽象接口更接近于它的使用者(上层模块),所以看上去就像具体类依赖于上层模块一样,这才称之为依赖倒置. 如果严格按照DIP来讲,任何一条new语句就违反