奇幻RPG(物品锻造 与 Decorator模式)

物品锻造是各类奇幻游戏中的常见功能,就拿众所周知的Diablo来说吧。假设角色拥有一把单手剑,可能基础攻击力只有13,但是它有三个装备孔。当给剑镶嵌一颗蓝宝石的时候,它就拥有了额外的冰冻效果并多加2点攻击力;当给剑镶嵌一颗红宝石的时候,它又拥有了额外的火焰伤害并多加3点攻击力;当给剑镶嵌一颗绿宝石的时候,它又拥有了额外的中毒伤害并多加的4点攻击力。当然,也可以三个孔都镶嵌同一色的宝石。本文将说明如何使用Decorator模式来完成这样的设计。

使用继承来扩展

我们首先想到应该有个基类 Weapon,它供所有各式各样的武器继承,比如说Sword、Axe、Bow。Description字段代表武器的说明,比如“One-Hand light Sword”,Damage()方法则用于获取武器的伤害,GetDescription用于获取武器的说明。在不考虑宝石的情况下,我们得到下面的设计:

现在我们考虑如何创建镶嵌有宝石的武器。我们首先考虑到可以用继承来实现这样的设计,结果却发现如果我们需要定义所有嵌宝石的剑(Sword),就需要3+6+7 = 16个类(NOTE:三个物品孔,每个孔都有 蓝、红、绿 三种选择,可以两个或者三个孔同一色),如果我们给镶嵌了两颗蓝一颗红宝石的剑命名为 Blue2RedSword,给三色不同不剑命名为BlueRedGreenSword,其余的类推。那么,我们会得到下面这样庞大的类体系(只绘制了部分):

而这仅仅是开始,如果我们需要再添一种宝石,比如说白色,它可以附加诅咒的效果;或者我们需要给武器再添加一个物品孔,那么我们的类的数目将迅速的由十几个变成几十个。

我们发现使用继承的问题:使用继承时将会创建出大量的类。除此以外,使用继承,也意味我们需要实例化一个特定的子类以获取我们需要的功能(方法),这在编译阶段(compile time)就已经确定,类的客户端不能控制何时(run time)根据需要改变,除非再实例化另一个子类。

使用复合来扩展

我们发现继承会带来两个主要的问题,所以我们考虑换一种方式来思考,我们可以使用复合来完成它。说详细一点,就是我们将蓝宝石(BlueDiamond)、红宝石(RedDiamond)、绿宝石(GreenDiamond) 作为实体变量(instance variable)复合到基类中,然后在基类的Damage()方法中计算出所有宝石额外增加的伤害(此时基类的Damage()方法不再是抽象的)。

public abstract class Weapon{
    public virturl int Damage(){
       int total = 0;
       if(redDiamond!=null)
           total += redDiamond.Damage();       //附加红宝石的伤害
       if(blueDiamond!=null)
           total += blueDiamond.Damage();      //附加蓝宝石的伤害
       if(greenDiamond!=null)
           total += greenDiamond.Damage();     //附加绿宝石的伤害
       return total;
    }
}

而在实体子类中,我们覆盖这个方法,在方法内部先调用基类方法获取宝石的附加伤害,然后再给它加上武器本身的伤害。

public class Sword: Weapon{
    public override ind Damage(){
       return base.Damage() + 15; // 15 是剑本身伤害
    }
}

此时的图应该变成这样:

相对于继承,复合看上去要好得多,它的类的数目要少的多,并且又可以在运行时决定是否给武器镶嵌宝石,但是使用复合仍存在问题:

  • 宝石与剑是紧密耦合在一起的,当我们想要为武器添加一个白宝石,那么我们需要给Weapon基类再添加一个BlueDiamond字段,同时还需要修改基类的Damage()方法。简言之,每次维护我们都要修改以前的代码。
  1. 我们遗忘了一种组合,应该记得,我们的剑是可以镶嵌三个同色宝石的,比如说:三个蓝宝石或者 三个红宝石,那么上面的设计显然无法完成。当然,我们可以从三种宝石中抽象出一个Diamond基类来,而在Weapon中添加三个Diamond类型的变量。但是,问题依然存在:如果我们需要多添一个装备孔,那么我们又得再次修改Weapon类。

为对象添加状态和行为

现在假设我们不是一名软件设计者,而是一个游戏玩家,我们要为剑添加一枚红宝石,一枚蓝宝石,那么实际的操作顺序是什么呢?

  1. 我们当然首先要有一把剑。(需要先创建一个Sword对象,它只是把剑,不含任何宝石)。
  2. 我们为剑添加一个红宝石。(我们包装Sword对象,给它添加3点伤害,并给它火焰效果)。
  3. 我们为剑添加一个蓝宝石。(我们包装 包含了一个红宝石的Sword对象,给它添加2点伤害,并给它冰冻效果。)

用代码来体现应该就是这样的:

Weapon sword = new Sword();             // 创建一把剑
sword = new RedDiamond(sword);          // 给剑添加 红宝石
sword = new BlueDiamond(sword);         // 给剑添加 蓝宝石

从给剑添加红宝石那句代码,我们发现第一件事:宝石应该保存一个对剑的引用。然后我们就可以在宝石类的内部来为sword添加行为或状态。

从给剑添加蓝宝石那句代码,我们发现第二件事:添加了红宝石的剑(仅从代码看它属于是宝石),仍然是剑,所以我们得出:宝石应该和武器是同一个类型(Weapon基类)的,不然这里将无法再次传递。

这个过程用图来体现就是这样的:

如果我们将整个过程用UML来表示,就构成了下面这幅图:

从图中我们可以看到,通过宝石的扩展,我们可以为剑提供新的能力:额外的伤害加成,以及额外的武器特效(抱歉我不能显示一个华丽的魔法效果,只能在黑底白字的屏幕上输出一句:Addtional Effect: Fire !)。

在Damage() 和 GetDescription()中,我们先调用基类的相应方法,然后为Damage()添加来自宝石的额外的伤害(状态): iceDamage,以及来自宝石的额外效果(行为):FrozenEffect()。

Decorator 设计模式

上面这幅图,就构成了GOF的Decorator设计模式,我们现在看一下它的官方定义:动态地为对象添加额外的职能。Decorator模式为通过继承来为类扩展功能这种方式提供了另一种灵活的选择。

代码实现与测试

简单起见,我们只实现一种武器:Sword,两种宝石:蓝宝石 和 红宝石。

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

namespace Decorator {

// 定义Weapon基类
    public abstract class Weapon {

protected string description;           // 武器的描述(攻击效果)

public virtual string GetDescription() {
           return description;
       }

public abstract int Damage();           // 武器的伤害
    }

// 定义剑
    public class Sword : Weapon {
       public Sword() {
           description = "One-Hand light Sword";
       }
       public override int Damage() {
           return 15;
       }
    }

// 定义宝石基类
    public abstract class Diamond : Weapon {
       protected Weapon weapon;        // 保存对武器的引用
    }

// 定义蓝宝石
    public class BlueDiamond : Diamond {
       private int iceDamage = 2;          // 蓝宝石的额外伤害

public BlueDiamond(Weapon weapon) {
           this.weapon = weapon;        // 保存引用
       }

public string IceEffect(){
           return "\nAddtional Effect: Frozen !";
       }

public override int Damage() {
           return weapon.Damage() + iceDamage; // 攻击加成
       }

public override string GetDescription() {
           return weapon.GetDescription() + IceEffect();  // 加入特殊攻击效果
       }
    }
    
    // 定义红宝石
    public class RedDiamond : Diamond {
       private int fireDamage = 3;         // 蓝宝石的额外伤害

public RedDiamond(Weapon weapon) {
           this.weapon = weapon;        // 保存引用
       }

public string FireEffect() {
           return "\nAddtional Effect: Fire !";
       }

public override int Damage() {
           return weapon.Damage() + fireDamage;    // 攻击加成
       }

public override string GetDescription() {
           return weapon.GetDescription() + FireEffect(); // 加入特殊攻击效果
       }
    }

class Program {
       static void Main(string[] args) {
           Weapon sword = new Sword();     // 创建一把新剑
           // 打印其描述(攻击效果) 和 伤害
           Console.WriteLine(sword.GetDescription() + "\nDamage:" + sword.Damage());
           Console.WriteLine();

sword = new BlueDiamond(sword); // 给剑添加一颗蓝宝石
           Console.WriteLine(sword.GetDescription() + "\nDamage:" + word.Damage());
           Console.WriteLine();

sword = new RedDiamond(sword);  // 给剑添加一颗红宝石
           Console.WriteLine(sword.GetDescription() + "\nDamage:" + sword.Damage());
           Console.WriteLine();
       }
    }
}

输出为:

One-Hand light Sword
Damage:15

One-Hand light Sword
Addtional Effect: Frozen !
Damage:17

One-Hand light Sword
Addtional Effect: Frozen !
Addtional Effect: Fire !
Damage:20

总结

本文中,我们通过一个常见的给武器(对象)添加宝石(额外的状态和行为)的例子,讨论了Decorator设计模式的实现过程。

我们首先提出了要解决的问题:给武器添加宝石,以使它有额外的攻击(伤害)加成和特殊的攻击效果。然后提出了使用继承会遇到的问题:大量的类以及只能通过实例化子类的方式获取行为。随后我们使用复合(Composition)的方式来解决,又遇到新的问题:程序不易维护,每次添加新的宝石或者添加新的物品孔,都需要修改代码。最后,我们使用Decorator模式巧妙地解决了这个问题。

希望这篇文章能给你带来帮助!

时间: 2024-08-29 16:16:29

奇幻RPG(物品锻造 与 Decorator模式)的相关文章

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

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

Java装饰模式(Decorator模式)

Decorator常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油漆的对象我们称decoratee.这两种实体在Decorator模式中是必须的. Decorator定义:动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活. 为什么使用Decorator 我们通常可以使用继承来实现功能的拓展,如果这些需要拓展的功能的种类很繁多,那么势必生

Decorator模式

Decorator模式 在开发过程中,有时会遇到需要向已经定义好的类添加新功能的需求,这时候通常的做法就是定义一个新类,继承这个类,在新类中添加新功能. 采用继承的方式来实现,在使用时,我们经常使用父类的指针或引用通过多态技术来调用子类的接口,但这样就会遇到一个问题:再向子类添加方法时,也需要向父类添加方法,否则通过父类指针或引用就调用不到这个方法.所以Decorator模式没有采用继承来实现,而是采用组合的方式来实现.类结构图如下图所示: 类ConcreteComponent和类Decorat

装饰(Decorator)模式

1.装饰(Decorator)模式    动态给一个对象添加一些额外的职责.就增加功能来说,装饰模式比生成子类更为灵活.Component是定义一个对象接口.可以给这些对象动态地添加职责.ConcreteComponent是定义了一个具体的对象,也可以给这个对象添加一些职责.Decorator,装饰抽象类,继承了Component,从外类来扩展Component类的功能,但对于Component来说,是无需知道Decorator的存在的.至于ConcreteDecorator就是具体的装饰对象,

连载:面向对象葵花宝典:思想、技巧与实践(40) - DECORATOR模式

掌握了设计模式之道后,我们将以全新的方法来理解设计模式,这个方法更简单.更直观,不信?看几个样例就知道了 ===================================================================== DECORATOR模式(以设计模式之道来理解) [业务] 假设你进入了一个信息安全管理非常严格的公司,这家公司不允许员工自行打印文档,所有的文档打印都需要交给文档打印系统统一管理.文档打印系统会记录每次打印的时间.内容.打印人员......等等,以便后续

Decorator模式 装饰器模式

Android 使用了装饰器模式 1. 概述 若你从事过面向对象开发,实现给一个类或对象增加行为,使用继承机制,这是所有面向对象语言的一个基本特性.如果已经存在的一个类缺少某些方法,或者须要给方法添加更多的功能(魅力),你也许会仅仅继承这个类来产生一个新类—这建立在额外的代码上. 通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法.但是这种方法是静态的,用户不能控制增加行为的方式和时机.如果  你希望改变一个已经初始化的对象的行为,你怎么办?或者,你希望继承许多类的行为,改怎么办

浅谈设计模式之八——Decorator模式

先上uml图: 意图:动态地给一个对象添加一些额外的职责.就增加功能来说,Decorator模式相比生成子类更为灵活. uml解析:装饰者模式又名包装器,顾名思义就是给某个对象添加一些功能,而不是给整个类添加一些功能.Component跟Decorator是聚合关系,子类ConcreteDecoratorA和ConcreteDecoratorB实现具体对Component的修饰. 下面给出可执行的示例代码: Decorator.h #pragma once #include <iostream>

Structual设计--Decorator 模式

1.意图 动态的给一个对象添加额外的职责.就增加功能来说,Decorator模式相比生成子类更为灵活. 2.别名 包装器Wrapper. 3.动机 有时,我们希望给某个对象而不是整个类添加一些功能.例如,肯德基推出特价套餐,如果套餐1中有:汉堡和鸡腿和价格,套餐二中有:薯条和汉堡和价格,如果做继承类,而且是多继承明显不够灵活,那么就需要装饰类. 4.适用性 以下情况使用Decorator模式 在不影响其他对象的情况下,以动态.透明的方式给单个对象添加职责. 处理他那些可以撤销的职责. 当不能采用

Android学习CursorWrapper与Decorator模式 (转至http://www.cnblogs.com/bastard/archive/2012/05/31/2527944.html)

一 Decorator模式 意图: 动态的给一个对象添加一些额外的职责.就增加功能来说,Decorator模式相比生成子类更为灵活. 动态的给一个对象,而不是对整个类添加额外职责,说明此模式将采用的结构是组合而不是继承: 要给一个对象添加职责,通常可以使用其类的派生类对象替换当前对象,但这显得不够灵活, 继承结构属于静态形式,系统往往并不知道有这样的类存在: 而我们需要的在某些时刻让对象具有一些额外的职责,额外的职责很可能是来自我们自己的扩展或者某些时刻的特定需求等. 于是通过一种方式对现有的对