今天继续设计模式之旅,给大家带来装饰者模式,国际惯例,先看定义。
装饰者模式:若要扩展功能,装饰者提供了比集成更有弹性的替代方案,动态地将责任附加到对象上。
先简单描述下装饰者模式发挥作用的地方,当我们设计好了一个类,我们需要给这个类添加一些辅助的功能,并且不希望改变这个类的代码,这时候就是装饰者模式大展雄威的时候了。这里还体现了一个原则:类应该对扩展开放,对修改关闭。
下面进入正题,今天在那看电影,忽然想起年轻时在游戏场上的血雨腥风啊,哈哈,下面以游戏为背景介绍装饰者模式。玩过游戏的兄弟应该都知道,游戏里面每个角 {MOD}有武器、鞋子、护腕、戒指、还有各种红宝石、蓝宝石、黄宝石等等。
下面需求开始:设计游戏的装备系统,基本要求,要可以计算出每种装备在镶嵌了各种宝石后的攻击力和描述:
具体需求:
1、武器(攻击力20) 、戒指(攻击力5)、护腕(攻击力5)、鞋子(攻击力5)
2、蓝宝石(攻击力5/颗)、黄宝石(攻击力10/颗)、红宝石(攻击力15/颗)
3、每个装备可以随意镶嵌3颗
好了,需求介绍完毕,当然了,不要吐槽我的设计,尼玛鞋子哪来的攻击力,关键时刻也是可以砸人的嘛。下面开始初步的设想,出于多年面向对象的经验,我们可能会这么设计:
如果你这么设计了,我靠,就这么点需求你写了几百个类,随便添加两个宝石,哈哈,指数增长听过么,准备加班吧。
可能你还会这么设计:写一个超类,然后里面各种set宝石,然后在计算攻击力的地方,使劲的If有哪几种宝石,恭喜你,代码量不是很大,但是随便添加个武器,你得又多写多少个IF呢。
上面叙述了一些可能性的设计,都不是很好,下面看看如何将装饰者模式融入:
首先是装备的超类
[java] view
plaincopy
-
package com.zhy.pattern.decorator;
-
-
-
-
-
-
-
-
public interface IEquip
-
{
-
-
-
-
-
-
-
public int caculateAttack();
-
-
-
-
-
-
-
public String description();
-
}
然后分别是武器、戒指、护腕、鞋子
[java] view
plaincopy
-
package com.zhy.pattern.decorator;
-
-
-
-
-
-
-
-
public class ArmEquip implements IEquip
-
{
-
-
@Override
-
public int caculateAttack()
-
{
-
return 20;
-
}
-
-
@Override
-
public String description()
-
{
-
return "屠龙刀";
-
}
-
-
}
[java] view
plaincopy
-
package com.zhy.pattern.decorator;
-
-
-
-
-
-
-
-
public class RingEquip implements IEquip
-
{
-
-
@Override
-
public int caculateAttack()
-
{
-
return 5;
-
}
-
-
@Override
-
public String description()
-
{
-
return "圣战戒指";
-
}
-
-
}
[java] view
plaincopy
-
package com.zhy.pattern.decorator;
-
-
-
-
-
-
-
-
public class WristEquip implements IEquip
-
{
-
-
@Override
-
public int caculateAttack()
-
{
-
return 5;
-
}
-
-
@Override
-
public String description()
-
{
-
return "圣战护腕";
-
}
-
-
}
[java] view
plaincopy
-