设计模式三重天[之一]

写作背景：

       一直在看关于设计模式的书并不断的实际工作中努力实践，同时也看到了播客园上设计模式
团队文章热火朝天的研究和讨论。心里非常高兴，在国内设计模式的研究和使用还不是很丰富和
完善的今天，这种讨论无疑会对每个园中的个体还是播客园整体实体的提升有着重大的意义，我
非常希望以后想研究.NET程序的人只要知道两个网址就能完成工作中90% 的知识查询，一个是微
软的MSDN，一个就是播客园。

        注：本文不是专门研究某一种设计模式，而是从全局出发，通过本人将近 1年半的学习和研
究设计模式后形成的一些个人观点在这里进行一下阐述，因为个人的能力有限，这里只是希望与
大家交流设计模式的学习心得，如果有些观点与您的相似或不同，欢迎大家与我联系。如某些观
点让某些人不舒服，欢迎拍砖。

       第一重：[模式 呀 魔式]
         
      本人在刚开始学习设计模式时只看了几个，包括:Strategy,Composite,Singleton，Factory这四个
模式，从一开始感觉的头大到后果看到了这几种模式给程序设计和修改以及调试所带来的便利好
处，让我对那四位大仙真是伸大指佩服。再以后就是又看了其余的一些模式，但越研究越发现，
这些模式就像是一堆同父异母的孩子，有些地方长得很相以，如果不是很了解这一家人，有时很
容易就会张冠李戴了，举个例子：Abstract Factory,bridge, Strategy 这三个就有点相似，如果大家
不相信，可以看一下相关的图文说明[特别是图的右半部分 ]。我想这也是在这一时期大家有时感
到迷糊的原因之一，到底该如果去分清呢？在一些偶然的机会下，我去下载一份RedSword软件工
作室的设计模式迷你手册[因为本人的模式资料只是从网上获取 ]，最开始的一个图表引起了我很
大的兴趣，图如下：

 

       并且手册上也把这些模式分成了三种类型，这三个类型对我后来理解设计模式又引入了新的
思考方向，它们分别是创建型，结构型和行为型，而上面提到过的那三个模式分别归属于这三个
类型：如Abstract Factory属于创建型，bridge属于结构型，而Strategy属于行为型，这时我才有些
开窍，原为这是因为出于在程序设计运行时在从对象的创建，到其中的结构演化到后来的表现行
为模式这几个部分来进行研究的。真是有些惭愧，因为一开始我觉得这是那四位大师顾弄玄虚呢
。
   
       而这时再回到上面所看的那个类似于蜘蛛网或者说是地图的那个图上，我才恍然大悟。原来，
设计模式之后的关联转换是有着千丝万缕的联系的。其实到后来我看这张图越看越象是人体的七
经八脉图，其中的那些箭头很像是人体血液在人的外界行为模式影响下沿着一定的方法有序流动。
而Composite有些象人的大脑，与它身边有着联系深化的模式多达8种。而Strategy模式又与创建型
模式中的大部分模式有着单线联系。其中的Strategy->Template Method-->Factory Method<--
Abstract Factory恰恰能够解释为什么Strategy，Abstract Factory在结构的右半部有非常相似的图文
和代码样式，原来两者一个是出于对Template Method中处法具体实现的步骤[Strategy],而别外一个
却是出于对TemplateMethod模式的在创建对象使用方法上的进行了系列化的实现[Abstract Factory]。

        这也再次说明了了解那三种类型对于设计模式理解上的重要性。

        这一个阶段我犯的最大错误可能就要说是对设计模式所提供的代码过于机械性的理解了，
虽说它能让你一开始很快将一种模式付诸实现，但由于示例代码本身没有专深的业务应用背景，
同时，还有可能会把一些以后开发用不上的代码也带入系统，增加系统的代码维护量，另外还会
让维护人员对系统产生不必要的误解。本人曾经在1年前的一个网站开发项目中犯了这个错误，
最后导致开发的系统内核和未来要进行的开发难度过高而被放弃，最后还是使用最保守的方法完
成了工作才得以解脱。

        另外这个阶段的程序员往往都有很高的热情，希望能将所学到的模式的知识转化为生产力，
从而导致在设计中不顾任何条件就使用了某种刚刚学到的模式。也许这对于他本身的知识积累来
说是件好事，但对于公司未必是好事一件，因为任何一种新技术在转化为生产力时都会存在一定
的风险，如果风险回避不好，很容易造成丢了夫人又折兵的境地。当项目经理一次又一次去问你
开发进度如何，客户不断在摧促你完成不断变化的需求时，我想再好的出发点最终都只是一种单
相思了。因此，我建议当对一种模式了解的同时，也要清楚自己目前的时间和精力，是否允许我
们去做出相关设计或者改进。另外，对设计模式的应用背景一定要非常清楚，千万而不要生搬硬
套，因为任何一种设计模式都是以代码量换取程序的灵活性和可扩展性的，编写和测试代码本身
就是一种时间和精力上的巨大付出，因为一定要预留足够的时间给自己。

        还有一个程序员只是关注设计模式书本上的知识，认为看了懂了就是所谓的精通了，孰不知
设计模式也像英语口语一样要经常反复的看了理解，因为模式本身就是从实践中来的，将来必定
会回到实践中去，一味纸上谈兵，最后只能是一场空。

        最后一句话，模式不在于你知道和了解有多少种，一切只以好用，易扩展，易维护等软件工
程上常用的衡理标准为准。一味的只重形式或只为实现模式而使用模式，最终都有可能会像武侠
小说中常说的那样-----“走火入魔”。

        未完....