依赖注入那些事儿Word文档下载推荐.docx

上传人:b****4 文档编号:6419372 上传时间:2023-05-06 格式:DOCX 页数:47 大小:318.62KB
下载 相关 举报
依赖注入那些事儿Word文档下载推荐.docx_第1页
第1页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第2页
第2页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第3页
第3页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第4页
第4页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第5页
第5页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第6页
第6页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第7页
第7页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第8页
第8页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第9页
第9页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第10页
第10页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第11页
第11页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第12页
第12页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第13页
第13页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第14页
第14页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第15页
第15页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第16页
第16页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第17页
第17页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第18页
第18页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第19页
第19页 / 共47页
依赖注入那些事儿Word文档下载推荐.docx_第20页
第20页 / 共47页
亲,该文档总共47页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

依赖注入那些事儿Word文档下载推荐.docx

《依赖注入那些事儿Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《依赖注入那些事儿Word文档下载推荐.docx(47页珍藏版)》请在冰点文库上搜索。

依赖注入那些事儿Word文档下载推荐.docx

3.3.2不同活性多态性依赖注入的选择

4IoCContainer

4.1IoCContainer出现的必然性

4.2IoCContainer的分类

4.2.1重量级IoCContainer

4.2.2轻量级IoCContainer

4.3.NET平台上典型IoCContainer推介

4.3.1Spring.NET

4.3.2Unity

参考文献

1.1讨论会

话说有一个叫IGame的游戏公司,正在开发一款ARPG游戏(动作&

角色扮演类游戏,如魔兽世界、梦幻西游这一类的游戏)。

一般这类游戏都有一个基本的功能,就是打怪(玩家攻击怪物,借此获得经验、虚拟货币和虚拟装备),并且根据玩家角色所装备的武器不同,攻击效果也不同。

这天,IGame公司的开发小组正在开会对打怪功能中的某一个功能点如何实现进行讨论,他们面前的大屏幕上是这样一份需求描述的ppt:

图1.1需求描述ppt

各个开发人员,面对这份需求,展开了热烈的讨论,下面我们看看讨论会上都发生了什么。

1.2实习生小李的实现方式

在经过一番讨论后,项目组长Peter觉得有必要整理一下各方的意见,他首先询问小李的看法。

小李是某学校计算机系大三学生,对游戏开发特别感兴趣,目前是IGame公司的一名实习生。

经过短暂的思考,小李阐述了自己的意见:

“我认为,这个需求可以这么实现。

HP当然是怪物的一个属性成员,而武器是角色的一个属性成员,类型可以使字符串,用于描述目前角色所装备的武器。

角色类有一个攻击方法,以被攻击怪物为参数,当实施一次攻击时,攻击方法被调用,而这个方法首先判断当前角色装备了什么武器,然后据此对被攻击怪物的HP进行操作,以产生不同效果。

而在阐述完后,小李也飞快的在自己的电脑上写了一个Demo,来演示他的想法,Demo代码如下。

Code:

怪物

1:

usingSystem;

2:

usingSystem.Collections.Generic;

3:

usingSystem.Linq;

4:

usingSystem.Text;

5:

6:

namespaceIGameLi

7:

{

8:

///<

summary>

9:

///怪物

10:

/summary>

11:

internalsealedclassMonster

12:

13:

14:

///怪物的名字

15:

16:

publicStringName{get;

set;

}

17:

18:

19:

///怪物的生命值

20:

21:

publicInt32HP{get;

22:

23:

publicMonster(Stringname,Int32hp)

24:

25:

this.Name=name;

26:

this.HP=hp;

27:

28:

29:

角色

///角色

internalsealedclassRole

privateRandom_random=newRandom();

///表示角色目前所持武器的字符串

publicStringWeaponTag{get;

///攻击怪物

paramname="

monster"

>

被攻击的怪物<

/param>

publicvoidAttack(Monstermonster)

if(monster.HP<

=0)

Console.WriteLine("

此怪物已死"

);

return;

30:

31:

32:

if("

WoodSword"

==this.WeaponTag)

33:

34:

monster.HP-=20;

35:

36:

37:

攻击成功!

怪物"

+monster.Name+"

已死亡"

38:

39:

else

40:

41:

损失20HP"

42:

43:

44:

elseif("

IronSword"

45:

46:

monster.HP-=50;

47:

48:

49:

50:

51:

52:

53:

损失50HP"

54:

55:

56:

MagicSword"

57:

58:

Int32loss=(_random.NextDouble()<

0.5)?

100:

200;

59:

monster.HP-=loss;

60:

if(200==loss)

61:

62:

出现暴击!

"

63:

64:

65:

66:

67:

68:

69:

70:

71:

损失"

+loss+"

HP"

72:

73:

74:

75:

76:

角色手里没有武器,无法攻击!

77:

78:

79:

80:

测试代码

classProgram

staticvoidMain(string[]args)

//生成怪物

Monstermonster1=newMonster("

小怪A"

50);

Monstermonster2=newMonster("

小怪B"

Monstermonster3=newMonster("

关主"

200);

Monstermonster4=newMonster("

最终Boss"

1000);

//生成角色

Rolerole=newRole();

//木剑攻击

role.WeaponTag="

;

role.Attack(monster1);

//铁剑攻击

role.Attack(monster2);

role.Attack(monster3);

//魔剑攻击

role.Attack(monster4);

Console.ReadLine();

程序运行结果如下:

图1.2小李程序的运行结果

1.3架构师的建议

小李阐述完自己的想法并演示了Demo后,项目组长Peter首先肯定了小李的思考能力、编程能力以及初步的面向对象分析与设计的思想,并承认小李的程序正确完成了需求中的功能。

但同时,Peter也指出小李的设计存在一些问题,他请小于讲一下自己的看法。

小于是一名有五年软件架构经验的架构师,对软件架构、设计模式和面向对象思想有较深入的认识。

他向Peter点了点头,发表了自己的看法:

“小李的思考能力是不错的,有着基本的面向对象分析设计能力,并且程序正确完成了所需要的功能。

不过,这里我想从架构角度,简要说一下我认为这个设计中存在的问题。

首先,小李设计的Role类的Attack方法很长,并且方法中有一个冗长的if…else结构,且每个分支的代码的业务逻辑很相似,只是很少的地方不同。

再者,我认为这个设计比较大的一个问题是,违反了OCP原则。

在这个设计中,如果以后我们增加一个新的武器,如倚天剑,每次攻击损失500HP,那么,我们就要打开Role,修改Attack方法。

而我们的代码应该是对修改关闭的,当有新武器加入的时候,应该使用扩展完成,避免修改已有代码。

一般来说,当一个方法里面出现冗长的if…else或switch…case结构,且每个分支代码业务相似时,往往预示这里应该引入多态性来解决问题。

而这里,如果把不同武器攻击看成一个策略,那么引入策略模式(StrategyPattern)是明智的选择。

最后说一个小的问题,被攻击后,减HP、死亡判断等都是怪物的职责,这里放在Role中有些不当。

Tip:

OCP原则,即开放关闭原则,指设计应该对扩展开放,对修改关闭。

策略模式,英文名StrategyPattern,指定义算法族,分别封装起来,让他们之间可以相互替换,此模式使得算法的变化独立于客户。

小于边说,边画了一幅UML类图,用于直观表示他的思想。

图1.3小于的设计

Peter让小李按照小于的设计重构Demo,小李看了看小于的设计图,很快完成。

相关代码如下:

IAttackStrategy接口

namespaceIGameLiAdv

internalinterfaceIAttackStrategy

voidAttackTarget(Monstermonster);

木剑

internalsealedclassWoodSword:

IAttackStrategy

publicvoidAttackTarget(Monstermonster)

monster.Notify(20);

铁剑

internalsealedclassIronSword:

monster.Notify(50);

魔剑

internalsealedclassMagicSword:

monster.Notify(loss);

privateInt32HP{get;

///怪物被攻击时,被调用的方法,用来处理被攻击后的状态更改

loss"

此次攻击损失的HP<

publicvoidNotify(Int32loss)

if(this.HP<

this.HP-=loss;

+this.Name+"

被打死"

///表示角色目前所持武器

publicIAttackStrategyWeapon{get;

this.Weapon.AttackTarget(monster);

role.Weapon=newWoodSword();

role.Weapon=newIronSword();

role.Weapon=newMagicSword();

编译运行以上代码,得到的运行结果与上一版本代码基本一致。

1.4小李的小结

Peter显然对改进后的代码比较满意,他让小李对照两份设计和代码,进行一个小结。

小李简略思考了一下,并结合小于对一次设计指出的不足,说道:

“我认为,改进后的代码有如下优点:

第一,虽然类的数量增加了,但是每个类中方法的代码都非常短,没有了以前Attack方法那

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 自然科学 > 物理

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2