生搬硬套设计模式坑害了多少人

看了这个帖子，有感写点废话
http://www.iteye.com/topic/243309

现在随便哪个面试不考点设计模式什么的，似乎就不叫面试，我倒想问问，面试官们你们自己不算那些死记硬背的，能记住多少模式的思想，又有多少是你们每天写的程序会用到的

我承认
1. 设计模式确实是前人总结的一些经验和良好的设计范式，是很有价值的
2. 把握良好的设计模式能够理清程序的骨架，使程序变得更清晰

但是我很想说的是

1.设计模式是最通用的一些程序设计方法和范式，不同的领域有自己的一些模式可以遵循，未必非得是那20几种里的某一个

2.书中列举的那些模式是死的，只是特定问题的一些设计思路，未必就非得那样，生搬硬套是很傻的行为

3.设计模式这东西没写过一定得代码量，看了书上写的那些也未必理解，代码量积累到一定程序（当然不是每天重复的体力劳动，需要勤思考），自然会对特定领域，或特定问题有自己的一套解决方法或者设计范式，很可能早就有了一套自己的组件库，所以也不需要去看书上那些死的东西，该会的你都会了，其他的你也用不到

所以基本上 面试时考个什么叫包装，什么叫工厂，抽象方法的实在是没什么意义，都成了背书了

举个最简单的例子，设计模式书上讲包装设计模式废了那么多笔墨，又是抽象类，又是接口的，累不累呀，其实可能天天都用的东西，不搞复杂点就不叫高深，这样难道不叫包装吗？

public interface Display{
     String display();
}

public class DisplayWrapper implements Display{
    private Display display;
    public DisplayWrapper(Display display){
        this.display=display;
    }
    public String display(){
        String s=display.display();
        //wrapper自己的处理
    }
}

很多程序员几乎认为，封装得不花个半天功夫根本找不到实现类在哪 这就是面向对象的美，就是面向对象的最高境界，简单的事情往往搞的N复杂

我就是想说 简单的就是最好的，简单的往往也是强大的

粗浅见解，有拍砖的欢迎

标题有误。你的意思应该是不能僵化的去考察设计模式的掌握。但是你这种说话的方式让大家很反感。你应该讨论的是如何考察一个人真实的面向对象设计水平，而不是会背几个设计模式。

lz是说overdesign的问题吧。。呵呵。。。
re一下，很多OO程序员都有overdesign的倾向啊。

看起来像个代理。。。
lz可能意思就是不要为了设计模式而设计模式
曾经看过一文，大体意思就是
什么事情都是向下兼容容易，架构师可以理解程序员，但是程序员很难理解架构师，之间架设个桥梁，让程序员在实现的时候可以更好的理解架构师的设计思想，就是设计模式的作用。
设计模式都是经验的积累，代码写的多了，到哪都是模式，没有大量的编程经验，凭空谈模式，肯定很生涩，没办法

我实在不理解我的言论有什么地方另你们不爽了

通常架构师早就对常用设计模式很熟悉了，但是单单说熟悉设计模式，那离架构师水平还差十万八千里呢

我就是鄙视那些张口闭口让谈谈设计模式的面试官们，一看就知道压根肚子里就没啥东西，所以就以为掌握那么几个设计模式就很nb了,可笑之极

不同意，设计模式是基础。。。一定要知道一些么。
无论你作不做架构师，即便是一个普通的代码民工显然也是需要知道设计模式的。。。

就像周星驰说的  “老佛爷是供在心里的，不是挂在嘴上的” 

要做到心中有剑， 灵活使用， 而不是为了模式而模式。

看你的回复，貌似是同意我的观点哦
可能是我表达的不清楚，我本来也不是说设计模式没有用，而是想说模式这东西靠的还是你通过有效代码的积累和思考而自然形成的一些经验总结，而不是书上的那几个死的名字

另外代码看多了，象工厂，包装，观察者这么common sense的东西肯定也早就很熟悉了

也许我该说设计模式书无用，还不如直接去找些好的源码来看来的实在

啊，这个啊。
我觉得结合着来看吧。。。。
逐渐增长经验，代码是比不可少的。

但是只读代码，有时候自己写的时候很难就能想到某个pattern正好合理，往往会走弯路。

我觉得，边看书，边读代码，边写一些自己的小项目是一个不错的学习方法吧。

能够掌握就很ＮＢ了，关键是在于应用在适合的场景，不要去套就ＯＫ了