【其他】设计模式有何不妥，所谓的荼毒体现在哪？

设计模式本身没有什么不妥，不妥的是滥用设计模式的人。

成文的设计模式本身是前人发现的在某种情况下非常自然的设计，但是问题是，能理解这个某种情况的人根本不需要去学什么设计模式，反过来，不能理解的人学了就有滥用的倾向。

成文的设计模式在几个dalao带着一帮菜鸡开发的时候非常有用。但是都是dalao的话就不需要，而都是菜鸡的话估计会让复杂度成倍增加。

设计模式就是写字本上的格子。

像我女儿这水平，写字离开了格子就歪歪扭扭，忽大忽小。

像我，白纸上写得几个碑帖正楷，倒也能横竖对齐，上下得体。

更有大家，拿去方格纸去求字，必被轰出来。

是白是黑，各自对号入座。若是我女儿不肯用方格本，必屁股上留下五指印。

过去的这几年，经历了一些复杂的大工程，对设计模式的体会更深了一些。所谓设计模式的问题不在设计模式本身，而在于开发团队的结构不健康，即该注重实现细节的基层岗位，牝鸡司晨，用Architect的工具解决一些轮不到他/她操心的问题。所以说认同“设计模式的流毒真的不少”的人，本身即没有工程经理的经验，也没有tech lead的经验，说的话也就听听而已，不用当真。

东施效颦你觉得恶心，可以，往死里黑，也可以！但你反过来骂西施，就不合适了吧！

至于有的人批评有关的教材，我只觉得，能有人把别人没有总结的，但又被广泛使用，而且有正面意义的东西，浓缩在一本书里，这是多大的功德？

举个例子，我们组这半年使用Node, Gulp, Angular积攒了一些经验，前两天隔壁组有人来找我们开个技术交流会，他们在做一款内部工具，基于Web，浏览器运行。主要负责的哥们是个Java Developer，一小时的会，有五十分钟都在给我们展示他的project（主要由jQuery, RequireJS构成），一个简单的Toolbar和里面几个button，把jQuery的轮子全部重新造了一遍，主要业务逻辑还没影呢，轮子的unit test已经达到了98%的覆盖率，Code Review时言必谈design pattern。

然而他的JS里面所有的class都用 var ClassName = (function ( ) {return {props..., func...} }( ) )，貌似父类和子类的继承关系，也是通过jQuery.extend(parentLiteralObject, childLiteralObject)。我们提出为什么不用prototype实现class时，哥们说他们是用到了"JavaScript Reveal Pattern"。我连续几遍强调不管什么pattern，你的method都不在prototype上面，而是在各自的instance上面。

最后我发现，哥们其实并不了解什么是prototype，怎样在JS中实现class和继承，以及前端开发中什么交给库来做，什么是真正的业务逻辑，并且采用Java applet 和 Swing等面向过程的方式来进行web前端开发。甚至于在函数中做参数检测时还不看具体情况的统一使用if (param != null) 这种模糊的逻辑判定。

不敢说荼毒，但事倍功半是肯定的。