WEB开发网      婵犵數濞€濞佳囧磹婵犳艾鐤炬い鎰堕檮閸嬬喐銇勯弽銊с€掗梻鍕閺岋箑螣娓氼垱笑闂佽姘﹂褔婀佸┑鐘诧工妤犲憡绂嶉崜褏纾奸弶鍫涘妼缁楁岸鏌熷畡鐗堝殗闁诡喒鏅犲畷褰掝敃閵堝棙顔忔繝鐢靛仦閸ㄥ爼骞愰幘顔肩;闁规崘绉ぐ鎺撳亹闁绘垶锕╁Λ鍕⒑閹肩偛濡奸悗娑掓櫇缁顓兼径妯绘櫇闂佹寧绻傞弻濠囨晝閸屾稓鍘甸柣搴㈢⊕閿氶柣蹇ョ稻缁绘繃绻濋崘銊т紝闂佽鍨伴崯鏉戠暦閻旂⒈鏁傞柛鈾€鏅欑槐妯衡攽閻愬樊鍤熷┑顔藉劤铻為柛鏇ㄥ墯閸欏繘鏌嶉崫鍕櫣缂佲偓婢跺绠鹃柟瀛樼箘閿涘秵顨ラ悙顏勭伈闁诡喖缍婂畷鎯邦槻婵℃彃顭烽弻娑㈠Ω閵夈儺鍔夌紓浣稿€哥粔褰掑极閹剧粯鏅搁柨鐕傛嫹 ---闂傚倷鐒︾€笛兠洪埡鍛闁跨噦鎷�
开发学院软件开发C语言 无废话C#设计模式之二十:Mediator 阅读

无废话C#设计模式之二十:Mediator

 2009-04-02 08:22:59 来源:WEB开发网 闂傚倷绶氬ḿ褍螞閹绢喖绠柨鐕傛嫹闂傚倷绀侀幉锟犲垂閻㈠灚宕查柟鎵閸庡秵銇勯幒鎴濃偓鐢稿磻閹炬枼妲堟繛鍡楃С濞岊亞绱撻崒姘扁枌闁瑰嚖鎷�婵犵數濮幏鍐川椤撴繄鎹曢梻渚€娼уú銈吤洪妸鈺佺劦妞ゆ帊鑳堕埊鏇㈡煏閸モ晛浠х紒杈╁仱閺佹捇鏁撻敓锟�闂傚倷绶氬ḿ褍螞閹绢喖绠柨鐕傛嫹  闂傚倷鑳舵灙缂佺粯顨呴埢宥夊即閵忕姵鐎梺缁樺姇閻忔氨鈧凹鍓熷娲垂椤曞懎鍓伴梺閫炲苯澧紒澶婄秺瀵濡歌閸嬫捇妫冨☉娆忔殘闂佷紮缍€娴滎剟鍩€椤掑倹鏆柛瀣躬瀹曚即寮借閺嗭箓鏌ㄩ悤鍌涘
核心提示:意图 用一个中介对象来封装一系列对象的交互,中介者使得各对象不需要显式相互引用,无废话C#设计模式之二十:Mediator,从而使其松散耦合,而且可以独立地改变它们之间的交互,它们所有的行为都提交到一个统一的地方(假设它是AccountSystem)去处理,这么做有几个好处:l 各大区不需要关心还有哪些其它的大区,场景

意图

用一个中介对象来封装一系列对象的交互。中介者使得各对象不需要显式相互引用,从而使其松散耦合,而且可以独立地改变它们之间的交互。

场景

我们知道,一个网络游戏往往有很多大区。每一个大区可以是一组服务器,也可以是多组服务器,在这里假设一个大区是一组服务器。为了效率,一般每个大区都会有一个数据库,玩家的创建角色、充值、消费行为只是在这一个大区中有效。现在公司有了新的需求,那就是玩家的一些信息能在多个大区中共享。比如,在注册的时候就把玩家的账户信息写入多个信息共享的大区,玩家在某个大区中充值需要“通知”其它大区修改账户余额,玩家在某个大区中消费也需要“通知”其它大区修改账户余额。

如果我们现在有ABC三个大区,下面的方法可以实现需求:

l         网站的注册方法调用A、B和C大区的注册方法

l         A大区的充值方法调用B和C的充值方法

l         B大区的充值方法调用A和C的充值方法

l         C大区的充值方法调用A和B的充值方法

l         A大区的消费方法调用B和C的充值方法

l         B大区的消费方法调用A和C的充值方法

l         C大区的消费方法调用A和B的充值方法

我想,没有人会这么做吧。你肯定会想到在一个统一的地方去维护所有大区的信息,任何一个大区的行为不直接和其它大区的行为关联,它们所有的行为都提交到一个统一的地方(假设它是AccountSystem)去处理。这么做有几个好处:

l         各大区不需要关心还有哪些其它的大区,它只直接和AccountSystem对话。

1 2 3 4 5  下一页

Tags:废话 设计模式 二十

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接