设计模式:桥模式

桥模式解决的是这样的一个情况:当一个对象有多个变化维度的时候,我们就可以用桥模式来优化;

什么意思呢?比如我写游戏遇到这样的情景:

现在有一个monster基类,他有Health脚本,也有FSM脚本,还有技能脚本和动作脚本,每个脚本都是一个变化方向,如果把他们都耦合到一个类里面来实现,那么是非常非常恶心人的一件事情,我们发布一种单位[继承Monster],都要重写一边所有脚本,代码重复非常非常严重,这个重复的原因是我们将每个脚本都耦合在一起了,比如我们只改变了FSM脚本,其他的脚本我们不需要改变,但因为高耦合性和继承带来的静态性质,我们不得不重写。

桥模式给了我们一个解决上面尴尬情况的解决方案,其核心思想是将每个变化维度独立出来,怎么弄呢?多态指针!看下面的UML图:

 我们将每个变化方向封装成一个类,然后继承接口,接着我们设计一个类,拥有每个变化方向的接口指针[姑且叫F类],这样,每个变化维度就都不相互干扰了;

示例代码如下:

class HealthBase {
protected:
	virtual void Do() = 0;
};

class Health1 :public HealthBase {
	//......
};

class FSMBase {
protected:
	virtual void Do() = 0;
};

class FSM1 :public FSMBase {
	//......
};

class BehaviorBase {
protected:
	virtual void Do() = 0;
};

class Behavior1 {
	//......
};

class MonsterBase {
public:
	HealthBase* Health;
	FSMBase* FSM;
	BehaviorBase* Behavior;

};

class Monster1:public MonsterBase {

};

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值