其实只要了解一些就差不多了,用到时才去学，我是最讲实用的

>精神实质：其实就两个字，封装和分派。
精辟之言

我最近设计的产品使用了多种设计模式，我认为设计模式在实际中有很广泛的应用。
不识庐山真面目，只缘身在此山中。大家在人家设计好的方案中写程序，当然看不到有设计模式的存在，程序员嘛。

最早是大概两三年前，第一次看到设计模式的书，就深深的被吸引，当时觉得很多地方实在是难懂，看了一些章节后，突然感觉开窍了，因为模式是为了解决实际问题而出现地，设计模式背后其实有着一些基本原则，比如松耦合、强内聚，所有的模式都是从这几个基本原则为出发点来解决实际问题的。

后来只是稍微看了看每个模式的背景，需要解决的是什么问题，而没有细致的去看每个模式究竟是怎么实现的。碰到实际问题的时候就想想自己会怎么做，有没有什么模式能解决这个问题。

我是个新手，最近也在看设计模式。刚开始我也是一头的劲，什么都是模式，什么都想用模式。可是最后发现一个程序是不是要用模式，真的要想清楚了。
不用模式也许我只要写一个类，用了模式我可能要写很多。
我同意设计模式是面向对象的东西，可是渐渐的我发现了，原来模式封装了变化，什么意思呢？如果你的系统的变化很多，那你一顶要用模式，可是如果你只是要做个小的东西，请问一个类能完成的，我为什么要用很多的类呢？？？
我现在的态度是：设计模式一定要知道，它能让你脱胎换骨。需要的时间我才从新翻翻，以完成工作！
在这里我真的很感谢《程序员》上的《设计模式电视机》的作者。ありがとう。

欣赏fiddle实事求是的严谨态度

但不认为学习设计模式好高骛远。OO与模式就象内功与招式，二者相辅相成。得心应手地使用模式应是OO 程序员的最高境界。当然OO设计模式是以扎实的OO功底为基础的。反之OO设计模式又可以加深对OO的理解。我们学习一堆OO的概念继承，封装，多态，如何用OO开发出高质量的code呢？借鉴前人的经验是最佳途径。那就是Design Pattern。我们通过模仿，学习模式来加深对OO的理解

当然大师级的人物如Bjarne Stroustrup ，James Gosling 即使不用模式也能写出顶级code。但有几人有他们那样OO深厚功力呢？

我1998年接触到GOF的Design Pattern翻了一下，觉得艰涩难懂就丢弃一边了。之后做了几个项目，碰到了一些问题。虽然最后都解决了，但是总决得很牵强。直到2003年重新拿起GOF的书，才发现很多问题其实可以用里边提供的模式来解决。所以我建议OO程序员应该读一下GOF的书，不用读懂但要记住它们的用处(Intent and Applicability)。当遇到问题时可以参考一下模式看是否可以解决问题。

欣赏fiddle实事求是的严谨态度

但不认为学习设计模式好高骛远。OO与模式就象内功与招式，二者相辅相成。得心应手地使用模式应是OO 程序员的最高境界。当然OO设计模式是以扎实的OO功底为基础的。反之OO设计模式又可以加深对OO的理解。我们学习一堆OO的概念继承，封装，多态，如何用OO开发出高质量的code呢？借鉴前人的经验是最佳途径。那就是Design Pattern。我们通过模仿，学习模式来加深对OO的理解

当然大师级的人物如Bjarne Stroustrup ，James Gosling 即使不用模式也能写出顶级code。但有几人有他们那样OO深厚功力呢？

我1998年接触到GOF的Design Pattern翻了一下，觉得艰涩难懂就丢弃一边了。之后做了几个项目，碰到了一些问题。虽然最后都解决了，但是总决得很牵强。直到2003年重新拿起GOF的书，才发现很多问题其实可以用里边提供的模式来解决。所以我建议OO程序员应该读一下GOF的书，不用读懂但要记住它们的用处(Intent and Applicability)。当遇到问题时可以参考一下模式看是否可以解决问题。