如何学习设计模式

      设计模式之于面向对象系统的设计和开发的作用就有如数据结构之于面向过程开发的作用一般， 其重要性和必要性自然不需要我赘述。

     然而学习设计模式的过程却是痛苦的， 从阅读设计模式的圣经——GoF 的《设计模式： 可复用面向对象软件的基础》 时的枯燥、 苦闷、茫无头绪，到有一天突然有一种顿悟；自己去实现 GoF 的 23 中模式时候的知其然不知其所以然， 并且有一天在自己设计的系统种由于设计的原因让自己苦不堪言， 突然悟到了设计模式中的某一个正好可以很好的解决问题，到自己设计的 elegant(优雅) 的系统时候的喜悦与思考；一直到最后向别人去讲解设计模式，别人向你咨询设计模式，和别人讨论设计模式。就如GoF 在其前言中说到： 一旦你理解了设计并且有了一种“Aha！ ” （而不是“ Huh？”） 的应用经验和体验后， 你将用一种非同寻常的方式思考面向对象设计。这个过程我认为是漫长的，painful， 但是是非常必要的。 经过了的才是自己的， Scott Mayer 在其巨著 《Effective C++》就曾经说过：C++老手和 C++新手的区别就是前者手背上有很多伤疤。是的在软件开发和设计的过程中， 失败、 错误是最好的老师， 当然在系统开发中， 失败和错误则是噩梦的开端和结束，因为你很难有改正错误的机会。 因此，尽量让自己多几道疤痕是对的。

     面向对象系统的分析和设计实际上追求的就是两点， 一是高内聚（Cohesion）, 而是低耦合（Coupling）。 这也是我们软件设计所准求的， 因此无论是 OO 中的封装、 继承、 多态，还是我们的设计模式的原则和实例都是在为了这两个目标努力着、贡献着。道不远人， 设计模式也是这般。 设计模式并不是空的理论， 并不是脱离实际的教条。 就如我们在进行软件开发的过程会很自然用到很多的算法和结构来解决实际的问题， 那些其实也就是数据结构中的重要概念和内容。 在面向对象系统的设计和开发中， 我们已经积累了很多的原则， 比如面向对象中的封装、 继承和多态、 面向接口编程、 优先使用组合而不是继承、 将抽象和实现分离的思想等等， 在设计模式中你总是能看到他们的影子， 特别是组合（委托） 和继承的差异带来系统在耦合性上的差别， 更是在设计模式多次涉及到。 而一些设计模式的思想在我们做系统的设计和开发中则是经常要用到的，比如说Template、Strategy模式的思想，Singleton模式的思想，Factory模式的思想等等， 还有很多的模式已经在我们的开发平台中扎根了， 比如说Observer（其实为Model－Control－View模式）是MFC和Struts中的基本框架， Iterator模式则在C++的STL中有实现等。 或许有的人会说， 我们不需要设计模式， 我们的系统很小， 设计模式会束缚我们的实现。 我想说的是， 设计模式体现的是一种思想， 而思想则是指导行为的一切， 理解和掌握了设计模式，并不是说记住了 23 种（或更多）设计场景和解决策略（实际上这也是很重要的一笔财富） ， 实际接受的是一种思想的熏陶和洗礼， 等这种思想融入到了你的思想中后，你就会不自觉地使用这种思想去进行你的设计和开发，这一切才是最重要的。

       之于学习设计模式的过程我想应该是一个迭代的过程， 我向来学东西的时候不追求一遍就掌握、 理解透彻（很多情况也是不可能的） ， 我喜欢用一种迭代的思想来指导我的学习过程。 看书看不懂、 思想没有理解， 可以反复去读、 去思考， 我认为这样一个过程是适合向我们不是有一个很统一的时间去学习一种技术和知识 （可能那样有时候反而有些枯燥和郁闷）。GoF 在《设计模式》 一书中也提到， 如果不是一个有经验的面向对象设计人员， 建议从最简单最常用的设计模式入门，比如 AbstractFactory 模式、Adapater 模式、 Composite 模式、Decorator 模式、Factory 模式、Observer 模式、Strategy 模式、 Template 模式等。我的感触是确实是这样， 至少 GoF 列出的模式我都在开发和设计有用到， 如果需要我这里再加上几个我觉得在开发中会很有用的模式：Singleton 模式、 Façade 模式和 Bridge 模式。