近读程序员第六期，有读者致信，言及模式必须有场景，空谈无用。其言词之激烈，语态之急切，实不为讨论、商榷姿态。然立论虽似有理，实需商榷，识之。模式范畴太大，这里就笔者熟悉的设计模式做一讨论，供参考。
—— 题记
我向来是推崇设计模式，花了较多的时间学习、使用、研究设计模式，并将自己在学习过程中的思考和体会会同编写的C++源码整理到了PDF文档（GoF 23种设计模式解析附C++实现源码），放在Blog中供免费下载，不到一月的时间即有1500++的访问下载量，足见对于设计模式的重视和学习期望。
由于是科班出生，接触编程算来也有5年多的时间了，从面向过程的范式到面向对象的范式；实际参与项目也有1年多的时间了，加上自己实现的编译系统（Visual CMCS），也算是做了一些实际的项目开发，从刚开始的只是介入Code，到后来自己要做设计、架构。OO的影响及其与面向过程范式的比较，无需我赘言。但是正如我在设计模式解析的后记中谈到的：只有真正理解了设计模式，才知道什么叫面向对象分析和设计。虽然看起来有些偏激和绝对，但是也确实是许多的经历和经验中的感触和感悟。这里有关于模式的几点感想列出来：
一、设计模式强调的是思想，而不是一门技术。这里有一个常见的误解（个人观点），
有人把设计模式视为一门技术，其实这是值得商榷的。我的理解是设计模式与其说是一门技术，更加应该是一种思想，一种OO设计的思想。设计模式实在应该属于面向对象分析和设计的范畴，和实际的编码关联反而很小。学习设计模式的过程，实际上是接受面向对象系统设计分析的熏陶，随风潜入夜，润物细无声，然后在OO开发和设计中你就会不自觉使用这些思想，你以就慢慢地体会到什么是OO的分析和设计。
二、道不远人。设计模式指导我们怎样去创建、维护、分配面向对象系统中的实体类，
以获得高内聚、低耦合的面向对象系统，从而提高系统的可维护性和可复用性。设计模式是OO的一些设计思想的一个总结（但不是全部），因此设计模式和OO的设计原则经验没有矛盾，而是殊途同归。这也是我在设计模式解析后记中突出强调的一点：设计模式不是空的理论，也不是脱离实际的教条。很多人把设计模式认为是一门新的技术，包括有人与我讨论过Template模式怎么和OO中的多态如出一辙。目前的情况是，很多人都是通过接触、使用一门支持面向对象特征的编程语言（如Java/C++/C#）而进入每个人所谓的面向对象的设计开发（很多时候很多进行的还是基于对象的开发设计），我们对于OO的理解和感悟很大程度停留在我们在代码中class关键字，停留在简简单单的extends（Java中）和：（C ++中）关键字上。很多人并没有在学习和熟练使用Java/C++/C#后去系统地学习OO的理论和思想，并且在实际编码中并没有说要用到设计模式的思想（当然很多时候可能也会在不自觉中使用了，只是不知道或者不承认），也能完成所谓的设计和开发。然而当系统膨胀的时候，当设计的任务落到自己身上，当系统在重构中不可自拔，当在程序员遭遇程序员3大郁闷（Death、税收和需求变更）之中的需求变更而因为设计的原因而甚至要重新来过的时候，设计模式就慢慢地张现功效了。
三、纸上谈兵与熟谙兵法。兵法之于战争，其重要作用自是不可估量。然要求决胜于千
里之外、运筹帷幄之术，熟谙兵书是必然之道。尽管兵书战略和实际中的战斗有一定的差别，需要因地制宜，不至于纸上谈兵，但是这里有一个前提就是至少要熟谙兵法。设计模式有如OO系统设计和开发中的兵法，是的设计模式需要在真正的系统开发方才有实际意义，但是如果没有设计模式的学习，又怎么能够在实际的项目开发中使用设计模式。但是学习必须只能是轻量级的过程，因此学习设计模式的理论，并且对于设计模式的理论进行简化的模拟和实现，其意义也确实是非常重要和必要了。
