成功案例思科研发中心设计模式课程反馈

1、两天的课程，时间上相当紧张，是相当热烈，大家都相当满意。虽然是周末，场上座无缺席，虽然小组的形式不稀奇，案例分析却不断。预知详情，请看特邀通讯员发回的。学习和活动将根据培训计划陆续开展，敬请关注。9/129:00 12:00 上午场 特邀通讯员：Cnt Team Barry Jia 发回招展，人山人海课程开始前，Summer 先给大家了“工程与工艺”的道理。开发要关注的是代码的工艺，而设计模式恰好是代码工艺的完现。老师非常认同 Summer 的观点（貌似有点相见恨晚的感觉）。告诉大家不要只关注 tip（api, d），而忽略了 Skill(design pattern, architectur

2、e).学习设计模式，老师让大家先把“设计模式”抛开，先让大家考虑“优秀设计”？其评价标准的背后-关注开发总成本 Cost Total = Cost develop + CostMa ain。而 Cost Maain = Cost understand + Cost change + Cost test + Cost deploy。 在现实工作中 Cost Maain 总是远远大于 Cost Develop，的代码总是难以的，添加新功能总是很麻烦的，代码会让越来越“、”。“优秀设计”？对于设计，他有 3 项职责第职责:运行起来所完成的功能,这是模块存在的原因.第职责:要和阅读它的人比较容易理解.

3、第职责:它要应对变化,因为简单.,对模块不熟悉的应该能够要变化,开发者保证应该尽可能的第一职责很明确，要实现其功能。第二职责告诉而不是写出只有机器才能读懂的代码。而第三职责要写出能让人读懂的代码，需求总是会变的，干什么呢？所以不能也要设把需求改变认为是客户和的错，如果需求没有改变，那随之而变，学习设计模式就是为了让设计的能够更好的适应变化。而计的原则是“开放封闭原则（OCP）”。也就是加入新代码不需求修改老的代码。这对我们来说怎么可能？带着这个疑问老师把引入下一个。如何实现优秀设计？优秀设计发现变化/封装变化优秀设计解耦具体依赖优秀设计变化优秀设计精髓就是发现变化。将变化进行抽象、封装变化。同

4、时多种变化。一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里；同时一种可变性不应当与另一个可变性混合在一起。这样才能保证的可扩展性以及模块间的松耦合。而实现开闭原则有 2 个基本的，首先实现抽象，创建出固定却能描述一组任意个可能行为的抽象体,这个抽象就像抽象基类或者接口,任意个可能的行为就是可能的派生类。然后针对接口(抽象)进行设计，由于模块子间依赖一个固定的抽象,所以它对于更改可以是关闭的.9/1213:30 16:30 下午场特邀通讯员：Cnt Team Sanshi Zhang 发回深入浅出的讲解了优秀的设计以及著名的开放-闭合原则（OCP）。上午下午主要通过两个详实的案

5、例，具体分析设计模式在开发中的作用，一些熟知和不大了解的设计模式逐渐浮出水面，它们分别是策略模式、模板方法模式、桥接模式、观察者模式以及装饰模式。下午的课程从马云搬家案例入手，过程化功能分解经常产生“上帝类”，由于它们是万能的，因此很多相互关系不大的任务交织在一起，从而产生过长的方法定决这一问题的关键是要认识到面象的本质是“对象是非常具有责任心的东西”，对象应该清楚自己的职责范围，不要做越权的事情。由此引出本节课程的第一个实例VCD 出租， 需求描述和代码已经在附件03-Movie.doc 中。从代码中是Customer 类中存在过长方法sement首先看到（大概 100 行左右，占总代码量的

6、 50%左右），这和一再强调的函数设计三大原则（一是短小，二是短还是要短小）相。其次代码中存在过多的条件判断，这也增加了代码的复杂度。经过分析发现 sement 函数中处理的很多数据都不是Customer 类的数据，而是 Movie 和Rental 的数据，其实这是和 OO 设计的原则相违背的。特别引入了特性依恋（Feature Envy）来定义这种不关心本身类数据，而过多关注其它类数据的行为。最后通过如下三步走来完成对这一案例的重构：1.2.将Customer 中的费用计算和积分计算移到Rental 类中；使用 Strategy 模式将费用计算单独出来（这也是消除 if-else 过多的一个

7、常用方法）；使用 Template Method 模式将打印功能从 Customer 中提取出来，这样可以应对各种不同的打印需求变更。3.在分组和设计 PK 的过程中，大家对是否需要使用继承来对 Movie 进行重构有很大争议，最终觉得 Movie 类比较简单，未来需求的变化可以通过增加一个 movieType的简单数据类型来满足。本节课程的第二个例子是从编写一个简单的Log 类开始的，要求打印 Log 信息到文件系统，每一条Log 包含时间、线程 ID、需求在不断的提出：、Message 等基本信息。但是随着时间推移，1.为 Log 定义级别（包含 DEBUG，INFO，WARNING，ER

8、ROR），输出位置包括控制台和文件两种；输出格式分为文本文件和XML 文件两种；一条Log 可以输出到多个目的地，一条Log 可以有多种格式化。2.3.经过三次的需求变更后，Log 的代码已经变得越来越臃肿，可以参加附件 02-Log 原始代码.doc 。如何对这部分代码进行重构， 随后学习了 JDK Log带领Framework 的设计。其中主要用到了 Bridge 模式，还用到了 Template Method 模式、Observer 模式、Faade 模式。这里就先贴一幅整体类图，具体的阐述可以留在组内培训进行。9/139:00 12:00 上午场特邀通讯员：Platform Team

9、Seth Peng 发回培训 9 点开始，首先带领大家回顾了第一天的培训内容。经过昨天的培训，的培训风格已经熟悉，尤其是对模式设计的 PK 环“节情有独钟”。大家一改大家对昨天的拘束，每当 PK 时，都抢着主动上场show 自己组的设计，场面爆棚，热烈。上午的培训主要集中在“重构到模式”。通过案例和“牛人”的经典名言不断加深对重构的理解。在这些讲述中不断穿插各种模式的分析，并有很多自己独到的简介，而非简单的板书。比如讲授破窗效应时的和解释，生动形象，使大家一下就认识到不能因为已有的坏代码而加入的坏代码。在案例 PK 环节，主动出击，由qing 主讲，获得胜利。这次 PK 的案例是“加薪”系统，

10、大家对老师发的样例“差”代码首先了一番。看到需求列表，大家脑子里直接想到的就是“职责链”模式，随着你一言我一语的深入，qing 提出，可否加入“策略”模式，以解决未来可能的规则，大家本着“好的设计可以应对变化”的出发点仔细了“策略”模式，优化一番后，由qing主讲 PK，果然令老师都觉的很不错，他原本只想通过这个案例加深大家对“职责链”模式的理解，没想到组还加入了“策 略”模式，结果虽然另一组也很好，但是只是符合了，却没有像一样更进一步。大家也觉得这个方案更加主动，能够更好的适应未来的变化。最后，回顾了上午的培训内容，强调了重构在生命周期中的重要性。大家在拍过集体照后结束了上午的培训。总结上午

11、的培训，觉得还是受益颇多，尤其一组人一起思考问题，互补长短，更加有利于学习。这种积极互动的培训方式确实比简单板书更容易“推销”观点，也利于消化知识，主动思考。9/13 13:30 16:30 下午场特邀通讯员：Application QA Team Garry Wang 发回这是模式设计“”的最后一个下午，让忘记模式，而强调高效解决问题的设计就是好的设计。这样起 1990 年版的笑傲江湖，再教完令狐冲独孤九剑后，问去。还记得多少，说什么都不记得了，满意地踏风而识别坏味道。程序的坏味道呢？重复代码，过长方法，过长类，过长参数列表，发散式变化，式修改，特性依恋，数据泥团，基本数据偏执，switch

12、 语句这些都是坏味道。这些坏味道会让整个项目就像一栋有很多破窗户的大楼。所以要训练对坏味道的条件反射，最后达到“一看到坏味道的代码就”的境界。架构，设计，编码。很多高级程序员认为：做好的架构和设计，编码可以交给其他能力一般的程序员编写就可以了。编码的程序员就像建造大楼的民工兄弟，纯纯粹粹的体力劳动者。这种观点是错误的。老师提到了一个本一个概念源代码是设计。在设计阶段是不可能预知所有的产品的变化，只有在编码过程中才会发现，然后修正。这样反复的过程才能做出一个好的设计，编写出一个好的代码。就好象木桶一样，架构是一块板，设计是一块板，编码也是一块板，任何一块木板的短小，都会影响整个木桶的容量。认识重构，体会重构的意思。老师提到了一个破窗效应，当一栋楼有了破窗户，那么人们就不再在意是不是会有新的破窗户的产生。的代码也是如此，一旦有了坏味道， 那么坏味道就会越来越多。比如 if.else 的嵌套，很多时候大家在解决问题是，为了防止改动原有代码带来性的缺陷，而选择添加 if.else 的方法，这样坏味道就产生了，下个版本又依照这样的方式修复缺陷，那么坏味道就会越来越多。培训结束时，大家自发的以绵绵不断的掌声，来回应给带来的知识与欢乐。 两天的培训，虽然节奏有点紧凑，但诙谐生动的例子，精辟独到的给我留下了深刻的印象。让我感受最大的是，阅读和把握 code 的方式的变化