精辟之言
不识庐山真面目，只缘身在此山中。大家在人家设计好的方案中写程序，当然看不到有设计模式的存在，程序员嘛。
后来只是稍微看了看每个模式的背景，需要解决的是什么问题，而没有细致的去看每个模式究竟是怎么实现的。碰到实际问题的时候就想想自己会怎么做，有没有什么模式能解决这个问题。
不用模式也许我只要写一个类，用了模式我可能要写很多。
我同意设计模式是面向对象的东西，可是渐渐的我发现了，原来模式封装了变化，什么意思呢？如果你的系统的变化很多，那你一顶要用模式，可是如果你只是要做个小的东西，请问一个类能完成的，我为什么要用很多的类呢？？？
我现在的态度是：设计模式一定要知道，它能让你脱胎换骨。需要的时间我才从新翻翻，以完成工作！
在这里我真的很感谢《程序员》上的《设计模式电视机》的作者。ありがとう。
但不认为学习设计模式好高骛远。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)。当遇到问题时可以参考一下模式看是否可以解决问题。
但不认为学习设计模式好高骛远。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)。当遇到问题时可以参考一下模式看是否可以解决问题。