《大话设计模式》第29章-OOTV杯超级模式大赛—模式总结（六）
《大话设计模式》将于11月底由清华大学出版社出版
《大话设计模式》第29章-OOTV杯超级模式大赛—模式总结（一）
《大话设计模式》第29章-OOTV杯超级模式大赛—模式总结（二）
《大话设计模式》第29章-OOTV杯超级模式大赛—模式总结（三）
《大话设计模式》第29章-OOTV杯超级模式大赛—模式总结（四）
《大话设计模式》第29章-OOTV杯超级模式大赛—模式总结（五）
（接上一篇）
29.8 决赛
“欢迎回来，我们的短信平台刚刚关闭，结果已经出来。”GOF说，“除了四位入选的选手外，短信票数最多的选手是……她是……适配器小姐。”
适配器手捧住脸，刚才PK失利时都没有流泪的她，现在却梨花带雨，楚楚动人。相信她自己也没想到竟然会是自己，所有的人都将目光集中到了这个被称为有“杀手锏”的女孩身上。
“谢谢，谢谢观众朋友，我真心地……感谢……您们。” 适配器有些激动，有些泣不成声，和刚才的策略小姐的表现形成了鲜明的对比。
“好的，现在我们比赛已经进入了最高潮，23位选手，经过激烈的比拼，现在选出了五位选手将站在PK台上，来决定今天冠亚季军的归属。她们分别是……工厂
“决赛是一道应用题，希望五位选手根据你们的经验，来说明如果你参与其中，将会发挥什么样的作用，具体如何做。评委将根据各位的临场表现打分，最终评出冠亚季军。”GOF说道，“各位请听题。”
“题目是说有一家以软件开发和服务为主的创业型的公司创业初期初见成效，公司有了发展，员工数量大量增加，于是就考虑自主开发一套薪资管理系统来对公司的员工薪资进行管理，做得好也将作为产品对外销售。公司的员工按照薪资来分类大致可分为普通员工，他们按照月薪制发放，每月有工资和奖金；市场和销售人员，按照每月底薪加提成的方式发放；中高级管理人员，按照年薪加分红的方式发放；兼职人员和临时工，按照小时计费发放。系统要求界面不花哨，但要方便易用，如要有菜单、工具栏和状态栏等要素。产品初步打算用SQL Server作为数据库，但不排除未来成为产品后将可以应用于Oracle、MySQL等数据库来做数据持久化。薪资可以提供多种查询和统计的功能，报表能生成各种复杂的统计图。由于系统是自主研发的产品，所以统计图生成如若时间充裕则自行开发，否则就购买第三方的组件。”GOF念完题目后，接着说，“好了，现在请选手们准备一下，说出你们对这个系统设计的建议。”
“首先有请外观小姐发言。”
“我觉得这是一套典型的企业办公软件，所以在设计上我建议用三层架构比较好，也就是表示层、业务逻辑层和数据访问层。由于公司对业务有明确的需求，但对界面却有模糊性，‘不花哨’和‘方便易用’实在是仁者见仁，智者见智。所以我的建议是在业务逻辑与表示层之间，增加一业务外观层，这样就让两层明显地隔离，表示层的任何变化，比如是用客户端软件还是用浏览器方式表示都不会影响到业务与数据的设计。”外观小姐侃侃而谈。
“非常棒的回答，下面有请观察者小姐发言。”
“需求中提到‘要有菜单、工具栏和状态栏等要素’，其实不管是C/S架构还是B/S架构，每个按钮或链接的点击都需要触发一系列的事件。而所有的事件机制其实都是观察者模式的一种应用，即当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新，比如状态栏就是一个根据事件的不同时刻需要更新的控件。因为我觉得整个表示层，采用事件驱动的技术是可以很好地完成需求的。我说完了。”
“OK，下面有请适配器小姐回答。”
“本来我以为这个系统没我什么事，但是最后的需求，让我感觉我还是能发挥大作用。需求说‘统计图生成如若时间充裕则自行开发，否则就购买第三方的组件’，这里的意思其实就是说，统计图表的生成是自己开发还是购买组件是有变数的。既然这里存在可能的变化，那很显然要考虑将其封装，根据依赖倒转原则，我们让业务模块依赖一个抽象的生成图接口，而非具体的第三方组件或自行实现代码将有利于我们的随机应变。至于第三方组件的接口不统一的问题，完全可以利用适配器模式来处理，达到适应变化的需求。谢谢！”
“哈，看来题目难不倒各位模式的小姐。下面有请策略小姐发言。”
“轮到我了？好的，我是这么想的。公司有多种薪资发放规则，但不管用哪种发放规则，只不过是计算的不同，最终都将是数据的存储与展示，因此我们不希望发放规则的变化会影响系统的数据新增修改、数据统计查询等具体的业务逻辑。应用策略模式，可以很好的把薪资发放规则一个个封装起来，并且使它们可相互替换，这样哪怕再增加多种发放规则，或者修改原有的规则，都不会影响其他业务的实现。回答完毕。”
“Very Very Good！策略小姐的回答，非常精彩。下面有请最后一位，工厂
“只要是在做面向对象的开发，创建对象的工作不可避免。创建对象时，负责创建的实体通常需要了解要创建的是哪个具体的对象，以及何时创建这个而非那个对象的规则。而我们如果希望遵循开放-封闭原则、依赖倒转原则和里氏代换原则，那使用对象时，就不应该知道所用的是哪一个特选的对象。此时就需要‘对象管理者’工厂来负责此事[DPE]。比如需求中说到系统做成产品后可以用多种数据库来做持久化。如果我们创建对象时指明了是用SQL Server，那么就会面临着要用Oracle的时候的尴尬问题，因为这里不能适应变化。解决办法是我们可以通过抽象工厂模式、反射技术等手段来让业务逻辑与数据访问之间减少耦合。当然，如果系统比较复杂，也可以使用一种ORM工具来将业务对象与关系数据库进行映射。同样的道理，刚才提到的应用策略模式解决薪资发放规则，用适配器模式解决第三方组件适配等问题，在对象创建时，都可以通过工厂的手段来避免指明具体对象，减少耦合性。另外，在创建对象时，使用抽象工厂、原型、建造者的设计比使用工厂方法要更灵活，但它们也更加复杂，通常，设计是以使用工厂方法开始，当设计者发现需要更大的灵活性时，设计便会向其他创建型模式演化[DP]。总之，在面向对象开发过程中，为了避免耦合，都多多少少会应用工厂方法来帮助管理创建对象的工作。工厂方法的实现并不能减少工作量，但是它能够在必须处理新情况时，避免使已经很复杂的代码更加复杂[DPE]。工厂方法会继续努力，为大家做好优质的服务，谢谢大家。”《大话设计模式》
“哦，我对你的敬仰真如涛涛江水、连……”GOF突然感觉自己有些失态，连忙收口。“下面有请6位评委慎重做出选择，评出我们本届大赛的季军、亚军，以及我们的——冠军。现在是广告时间，不要走开哦，我们马上回来揭晓答案。”
场下，只见Hibernate双手紧握，举在胸前，ADO.NET则诧异地望着他。
Hibernate：“啊，工厂方法，我真是爱死你了。”
ADO.NET：“花痴，别犯傻了，人家可是大明星了，你爱到死人家也不会知道。”
Hibernate ：“我猜工厂方法准赢、确定赢、一定赢、肯定赢！”
ADO.NET：“那可难说得很。其他几位也表现很好的，主要原因是工厂方法最后一个回答，所以占了便宜，不然怎么能举出前面选手所说的例子，这其实都不太公平。”
Hibernate ：“咦，你说得对哦，为什么是工厂方法最后一个发言，按道理她应该第一个发言的。”
ADO.NET：“这谁知道呢，说不定又有什么潜规则在里面。”
Hibernate ：“啊，如果真是这样，那可实在是太让我这‘工仔’伤心了。”
ADO.NET：“‘公仔’？怎么听得像是广东香港那边对毛绒玩具的叫法。这是什么意思？”
Hibernate ：“你不知道呀，‘工仔’就是工厂方法的Fans的统称。”
ADO.NET：“啊，连粉丝统称都有了。太快了吧。”
此时，只听场外口号声四起。
“工厂工厂，公仔爱你，就像老鼠爱大米。”所有工仔们在简单工厂的指挥下举着条幅大叫道。
“模林至尊，策略同盟，号令天下，莫敢不从。”策略的粉丝开始齐呼。
外观的Fans坐不住了，跟着对叫道：“外观不出，谁与争锋。”
相比之下，观察者和适配器的Fans就显得没什么声势。《大话设计模式》
“各位现场的来宾，观众朋友们，第一届OOTV杯超级设计模式大赛的结果马上就要揭晓，让我们有请我们的总策划兼总导演抽象先生，上台来宣布结果。”
只见50多岁的抽象先生，缓缓走上台前，接过主持人GOF交给他的信封，对着话筒说：“真的很高兴能看到今天的大赛举办得圆满成功。在这我代表组办方，向所有为这次大赛付出艰苦努力的工作人员表示衷心的感谢。望着这23位模式小姐，她们在台上尽情地‘群模乱舞’，我们在台下感受到了她们的‘模法无边’。非常值得庆贺的是，23位小姐都发挥出了应有的水平，赛出了风格，赛出了水平。我……”
GOF打断了抽象先生的说话，“请您打开信封宣布结果。”
“哦，对对对，我是来宣布结果的。”抽象先生反应过来，拆开了信封，念道，“第一届OOTV杯超级设计模式大赛决赛入围的有：工厂方法、外观、观察者、策略、适配器。她们五位设
“抽象先生，请您宣布结果。”GOF不得不再次提醒他。
“哦，你等我说完，其实都是在不同层次、不同角度进行抽象的结果，它们的共性就是抽象。所以……”抽象先生打了个咯噔，“我宣布，第一届OOTV杯超级设计模式大赛的冠军是……”《大话设计模式》
（未完待续）
