设计模式与足球(二)

结构型模式

(6) 适配器模式:很多足球队都喜欢请外国教练(其中有一支我们都非常熟悉的国家队,名字偶就不说了,大家都懂的,微笑),外国教练请回来通常很难跟队员直接交流(语言不通),因此需要配翻译,此时,翻译充当了教练和队员之间的适配器,负责协调教练和队员之间的交流。

例如:pass --> shoot --> goal 转换 传球 --> 射门 --> 进球

适配器模式(Adapter): 将一个类的接口转换成用户希望的另一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

(7) 桥接模式:在足球比赛中,有人踢前锋、有人踢中场(前腰、中卫)、有人踢后卫;当然,有人习惯踢左边、有人习惯踢右边、也有人喜欢站在中间,因此诞生了左中卫、右前锋、中后卫、右后卫等名词,难道这不是两个变化维度的组合吗?

桥接模式(Bridge): 将抽象部分与实现部分分离,使它们都可以独立地变化。

(8) 组合模式:2012年欧洲杯一共分为四个组,每个组四个队,每个队有23名球员,如果要用一个图来表示2012年欧洲杯全体球员及各国分组情况,不用说,一定是个树状图,组里有队,队里有人,如果想要召开B组(赛前公认的死亡之组)队员大会,在B组的节点上写下通知:“下午3点,召开重要会议,事关出线!”,想必荷兰、德国、葡萄牙、丹麦队员都会积极响应,随叫这几个“苦逼”队位于同一个节点的分支上呢?微笑

组合模式(Composite): 将对象组合成树形结构以表示“部分-整体”的层次结构,它使得客户对单个对象和复合对象的使用具有一致性。

(9) 装饰模式:现在足球服上的广告越来越多了,2012年欧洲杯夺冠热门之一(赛前预测)德国队队服胸前右边一个奔驰,左边一个阿迪,当然还可以继续增加,广告既没有改变球衣的用途和性能,还能起到装饰效果,增加收入,何乐而不为呢?就是半决赛没能够让巴神继续“思考人生”,悲催的德国队!增加新的广告,只需对原有球服继续装饰即可。

装饰模式(Decorator): 动态地给一个对象添加一些额外的职责,就扩展功能而言, 它比生成子类的方式更为灵活。

(10) 外观模式:为了给记者和球队(球员、教练等)提供一个交流的平台,欧洲杯组委会在每场足球比赛前后都安排了新闻发布会,记者可以通过新闻发布会来与球队进行沟通交流(虽然不是每个队员会出现在新闻发布会上),在此,新闻发布会充当了记者(客户端)和队员、教练(子系统)之间的外观角色。当然,新闻发布会并不会影响某位记者单独采访某位球员(这一点也与外观类的定义一致,微笑)。

外观模式(Facade): 子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加容易使用。

(11) 享元模式:同一个国家队的队员,他们都共享着一个伟大的称谓,即"XXX国家队队员",例如“意大利国家队队员”、“西班牙国家队队员”(一说到“中国国家队队员”就伤心,还是不说了,难过),因此,"XXX国家队队员"是一个可以共享的内部状态。但是在比赛过程中,每个队员身披不同号码的球衣,球衣号码是不能共享的,同一个国家队的队员每个人都拥有不同的号码,因此,球衣号码是不能够共享的外部状态。在享元模式中区分了对象的内部状态和外部状态。

享元模式(Flyweight): 运用共享技术有效地支持大量细粒度的对象。

(12) 代理模式:足球场外,球员转会是一个热门话题。转会当然离不开球员的经纪人,经纪人将球员的想法传递给另一家俱乐部。经纪人就是球员的代理,球员是目标对象,而经纪人是代理对象,经纪人隔离了球员和“客户端”,“拍广告,请找我的经纪人”,“采访,请找我的经纪人”......

代理模式(Proxy):为其他对象提供一个代理以控制对这个对象的访问。

results matching ""

    No results matching ""