com是什么网站,色无极网站正在建设中,吉林seo策略,注册公司流程网#xff08;清华大学出版社 《把设计模式用起来》书稿试读#xff09;
上一篇#xff1a;把设计模式用起来#xff01;#xff08;3#xff09;用不好模式#xff1f;之时机不对 为什么用不好设计模式#xff1f;——原理不明 难搞的顾客#xff1a;“抹这种霜#…清华大学出版社 《把设计模式用起来》书稿试读
上一篇把设计模式用起来3用不好模式之时机不对 为什么用不好设计模式——原理不明 难搞的顾客“抹这种霜真的能让我额头上的皱纹减少”
销售“当然啦只要你坚持使用我们的淡纹霜你脸的上细纹一定会比没有抹要少很多。”
难搞的顾客“你们有没有现成的测试数据提供三个对比组至少一年的数据一组不抹一组抹你家的最后一组抹那瓶比你家便宜200元的霜。请您现在就把三组测试人员前后一年的皮肤状态数据拿出来我要看下……”
销售“这个……” 作为类比再来看关于设计模式效果的对话如下
布道师“设计模式能让代码更好的应对未来的变化……”
难搞的程序员“不要和我说未来设计模式被世人广泛认识都30年了就没有现成的一些数据来证明它们的作用吗”
布道师“嗯具体一点您想看什么数据”
难搞的程序员“比如说有人于2000年在某项目的一段代码里用了P模式十年过后该项目经历无数修改依然存活。我想知道当初代码中参与了P模式的那些代码它们变化几何会不会已经面目全非”
布道师“我明白你的意思了一组应用了设计模式的代码当然也是代码所以你想观察号称可以‘更好应对变化’的设计模式自身会不会反倒没能扛过变化如果是就能证明设计模式就是泥菩萨过河自身难保徒有虚名”
难搞的程序员“是的。”
布道师“你的想法是错的。” “难搞的程序员”想要的数据倒是可以从不少论文中查到。我挑选了有延续关系的两篇分别是2007年的《An empirical study on the evolution of design patterns关于设计模式演化的一个实证研究》和2012年的《How changes affect software entropy: An empirical study变化如何影响软件熵值一个实证研究》。两篇论文的研究对象均为知名的开源软件系统它们是
表 3 两篇论文所用到的开源软件项目 项目 关键特征 研究数据时间跨度 备注 JHotDraw 中型项目/主要开发语言Java 3年 (2001~2004) 仅论文1使用 ArgoUML 中型项目/主要开发语言Java 论文15年 (2000 ~2005) 论文211年 (1998~2009) Eclipse-JDT 大型项目/主要开发语言Java 论文13年 (2001~2004) 论文210年 (2001~2011) Mozilla 大型项目/主要开发语言C 13年 (1998~2011) 仅论文2使用 Samba 中型项目/主要开发语言C 8年 (1996~2004) 仅论文2使用 下面列举两篇论文涉及到设计模式与代码变更关系的一些实证结果
在软件系统的演化进程中尽管有些设计模式指使用了设计模式的代码下同确实很少发生代码变更但有些设计模式变更剧烈甚至超过没有使用任何设计模式的代码确实有会一些设计模式比另一些模式在不同的项目中都显得更惰性变更少、代码稳定反过来有些模式明显比别的模式更善变一有变更首先动到的就是参与该模式的代码不同的设计模式产生频繁更改的代码位置也不尽相同有的喜欢改动类的属性、有的喜欢改类的方法有的改方法的实现还有的最喜欢添加子类参与设计模式的代码的变更频率以及它们所引发的其它代码的变更的数量取决于模式自身更多取决于模式所要实现的业务功能。越关键、重要的功能变更通常越剧烈相应的代码维护工作量也越大如果用错了设计模式那么后续发现问题加以订正时变更往往更加剧烈或许应该用“惨烈”来形容——无论是参与设计模式实现的代码还是涉及到的其它代码。 类似的实证结果还很多并且都很有趣也很值得大家找出这两篇论文细读加深思。不过此刻我们只需要得出一个最简单的结论应用了设计模式的代码并不能“以不变应对万变”相反更多时候设计模式是在“以变治变”。 举个论文中的实际例子参与代理Proxy模式的代码就容易被变更。《How changes affect software entropy: An empirical study变化如何影响软件熵值一个实证研究》论文基于ArgoUML项目的研究结果表明参与代理模式的类比不参与任何设计模式的类具有更高的变化熵也比参与复合、装饰器、工厂方法和观察者模式的类具有更高的变化熵而与单例、状态策略和模板方法等模式的变化熵没有显著差异In summary, results indicate that:Classes participating in Proxy design patterns have a higher change entropy than classes that do not participate in any design pattern, and than classes participating in Composite, Decorator, Factory Method, and Observer, while no significant difference can be found with Singleton, State Strategy, and Template Method. 。
为什么会这样呢让我们简单分析一下。假设在项目中PA代理A。如果A是一个无关紧要的功能具体表现为A功能做出来后无人问津同时A对其它功能也没有多大影响……这就是前述的结果③。另一种可能A功能非常重要总有人用总有人提建议或意见于是它一直在改进于是问题变成为什么A一修改包括增加特性PA就大概率地也要随之更改
答因为在代理模式中代理人不仅要对客户提供被代理人的功能而且还要调整被代理人对外提供的功能。如果我们用C来表示客户那么C、PA、A三者关系如下 PA的变化可能来自A。当A兴冲冲地增加了一些新功能或者气嘟嘟停用了某些功能作为代理PA 大概率需要同步这些变化。
PA的变化也可能来自C。当C意欲增加新的请求时PA必须同步增加对该项请求的处理。有意思的是这时候A可能响应变化也保持不动后者的意思是让PA先把这项请求应付下来。
如果变化仅仅来自两端那还不能称代理人善变。PA的变化极大可能来自自己事实上这正是代理模式中的代理人最喜欢干的事在C不知不觉和A不声不吭的状态下为了某些特定需要修改了某些请求修改了某些响应包括前面所说的抛开A自行处理、响应了C的一些请求。在真实的项目世界中存在大量A不太重要但PA很重要也就是“太监”比“皇帝”干的活多的情况。
PA只能代理A吗不现实世界中的项目一个代理类需要代理多个被代理类的情况并不少见。
综上所述可知参与代理模式的代码确实是善变的除非被代理人和代理人都不重要。我们真正关心的问题来了以Proxy模式为例一段善变的代码是如何帮助其它代码更好地应对变化呢我们让PA来说出答案它是含泪说的让C和A都守住单纯你们那些奇奇怪怪的要求冲我一个人来吧
典型的牺牲我一个幸福其他人。这就是Proxy模式发挥药效的基本原理。当然并不是所有的模式都有这种思想高度在本书后面的章节中我们将从源头上讲清楚每一种设计模式的发挥“药效”的原理。
现在就用一句话回答命令Command模式在让代码更好地应对未的变化这件事上原理是什么也是通过牺牲自己吗工厂方法Factory Method呢观察者Obsever呢如果你不能张口就来那么从对个别设计模式的认知还没达到知根知底的水平。 不屈不挠的丁小明“老师我是没办法一提某个模式就想到它的作用原理但我并不认为我用的设计模式都错了。”
“发烧吃退烧药流鼻涕就吃感冒药咳嗽厉害喝上半个月的止咳糖浆……”
“对啊烧退了感冒症状消失了咳嗽也停了这样不行吗”
“当病人可以当医生不行。”
