《设计模式——基于C#的工程化实现及扩展》

 

作者访谈录

 

针对王翔老师的新书《设计模式——基于C#的工程化实现及扩展》的出版，博文视点编辑小林对他进行了邮件专访，现将博文的编辑与王老师的对话整理成文，以飨读者。

 

博文小林

王翔老师，您好！您即将出版的《设计模式——基于C#的工程化实现及扩展》这本新书，是您结合项目经验撰写而成的。市面上已经有一些关于23种设计模式的书，有的已经获得了市场和读者的认可，您在文中重新介绍这23种模式时融入了哪些新元素，这些元素对读者会有哪些帮助？

王
翔

设计模式是套思想，我是一名从事开发的人员，有时候会觉得如何更巧妙地结合应用功能完成实现须要多多斟酌。

在我的师傅、同事和领导的帮助下，这几年做了一些.NET的项目，我酷爱C#语言，在使用中发现C#实现一些设计模式的时候有很多特色。

虽然本书很多模式的扩展都很有限，但我希望将其作为一个引子，能够与喜欢模式& C#语言的朋友有个讨论的基础，不断完善这部分内容。

从以上写作目的出发，我主要希望该书能够对实际工作有以下帮助：

打破一些固有的套路。

用C#以简洁、直接的手段解决易于变化的问题。

不要仅仅将依赖关系定格在对象体系上，应更多考虑到应用开发、运维不同生命周期中参与者的工作特点，将依赖拓宽到对象、配置体系、数据存储和服务体系。

面向Web、面向混合信息体系、面向服务。

博文小林

每个程序员都是有独立性格的个体，这些性格会给学习带来方法和思路上的影响，您认为程序员学习和使用设计模式来进行开发的时候最须关注的要点是什么？

王
翔

同为程序开发人员，我们在对待自己工作的时候总或多或少有些"止于至善"的心结。

代码、类库、应用框架不仅仅是老板和项目经理眼中的产品，更是我们敝帚自珍的工作成果，虽然我们可以接受"唯一不变的就是变化本身"，但修改自己的代码，尤其是因为上游需求不确定带来这种压力的时候，总不是愉快的。

我们要借鉴并应用那些成熟的套路，将变化抽象并集中在几个点，然后把它们交给运维人员来处理，而我们把时间更多地放在创造性的工作上。

所以，模式是现成的，但实现套路要靠自己。

如果说开发中我们用什么态度使用模式最重要，我自己的体会有两点：

敏思（不唯套路，同时不囿于局部）。

厉行（如果在适应变化、根据上下文需要应用某些或某个模式的时候，能够用语法支持的特性、FCL完成，则绝不随便构造一整套类型系统，而是直达目的）。

博文小林

《设计模式——基于C#的工程化实现及扩展》一书中，我们看到了您多年经验的积累和总结。那么对于一个设计模式的初学者，您对他（她）们在学习设计模式和本书时有什么好的建议？在遇到难以捉摸的问题时有什么比较通用且有效的解决办法？

王
翔

我是个比较循规蹈矩的人，所以我的建议可能收效会慢点。我认为设计模式虽然是思想，但需要对一个面向对象语言有比较扎实的基础。

以我自己为例。

接触.NET是因为有个项目我师傅觉得用.NET来实现不错，然后我去师傅那里抱佛脚，师傅打开.NET Framework SDK Documentation，指着语言参考的C#部分和Programming with.NET Framework说："这是你要的"。

不知道是不是有意指点我，记得那段时间他的MSN Personal Message 是"聪明人懂得下笨功夫"。

既然师傅这么安排，那我就一头扎进.NET SDK，7个月后.NET项目延期了，不过我把那些文档全部看完了，C#语言参考还看了两遍，所有的示例代码也都调试过了。

然后看到《设计模式：可复用面向对象软件的基础》，第一遍看的时候，经常觉得"哦，这个太Cool，有收获"，但第二遍看的时候，有很多地方会觉得"这么麻烦，用C#，一下子就OK了"。

所以，设计模式是思想性的东西，但需要在语言上多做些准备，学习的时候要敢于否定自己以前已经很熟悉的套路，甚至是经典中提出的套路，自己给自己一个不断突破的目标，经过批评和自我批评之后再看《设计模式：可复用面向对象软件的基础》，应该就有更多心得和收获了。

至于难点，我师傅也有句话——"重复的力量"，看不清楚就敲击键盘调试它，几遍之后会突然有一个顿悟的时刻。本书概念上最难的是Visitor模式，前面在Observer和Proxy也有个跳跃式的过程，您也可以用"重复的力量"击溃它。

博文小林

您在全国海关信息中心从事过很多大型的开发项目，您日常负责的工作主要是哪些？本书重视设计模式的工程化实现和扩展，这些工程化的内容与您的工作有哪些联系？在书中您是如何体现工程化思想的？

王
翔

我的工作职责主要有三个部分：

作为开发部门的高级技术架构师，主要负责行业业务系统的开发。

作为信息安全工作组的成员，参与公钥项目的实施和扩展。

作为优化小组的成员，参与行业主要业务系统的优化，务求Do more with less。

本书涉及的内容基本上都是从这几年工作经历中抽象、简化出来的，虽然书名有"工程化"，但其实更偏重"工程化实施的功能特性"，因为容错、保密、异常处理、高可用、锁和并发管理基本上没有体现在示例中。

不过本书中也提到了如何透明地加入这些机制，并且还介绍了可以即插即用的模式，希望您不要错过。

我工作的行业是一个快速变化的行业，最近几年每年的增长率都在20%以上，同时又随着全球化、区域化而快速变化。因为业务上的变化要求，技术上必须做出相应的处理，因此发现《设计模式：可复用面向对象软件的基础》后，我就再也没有放弃过它。

这几年行业的标准化程度有了质的跨越，外部环境中Web 2.0、SOA、云计算和纳米计算的概念也在兴起之中，所以书中很多地方提到的XML方式，既是顺应需要，又是不得已为之。希望其中一些粗浅的方法也能用在别的行业中。

博文小林

在经典的23种设计模式之外，您在书中还扩展了一些架构模式如Web Service模式，介绍这些并不属于经典模式的模式，您是出于哪方面的考虑？在深入这些模式之前需要有哪些必要的知识准备？

王
翔

项目需要，估计别人的项目中也已经越来越多地涉及了这些内容。

完成一个项目，不同类型的模式可能要兼容并包，"尺有所短，寸有所长"。

我有一点体会，不管什么类型的模式，哪怕它叫"架构"，都应该有个"作业面"（借鉴地质、能源行业常用的词），每次经过抽象和简化，不管什么模式其实面对的都是一个相对有限的小场景，头脑中保存的不是按层次分类的模式，而是一个长长的列表，然后根据上下文选择合适的，不要受架构层次一定要用所谓的架构模式、类层次一定要用《设计模式：可复用面向对象软件的基础》中那些对象关系的羁绊，基于组件化、服务化，我们已经可以较容易地拿捏出这个"作业面"。

至于这些扩展部分，准备知识恐怕还是经典的GOF23和相关领域的开发体会。

另外，比较遗憾，没能在本书中把数据访问模式、集成模式、公钥体系中的信息安全模式、XML设计模式和数据库设计模式涵盖进来，如果有幸再版，我希望可以把它们补充进来。