关于设计模式的几点误区

现在的设计模式越来越火，很多人动不动就说设计模式，好像设计模式无所不能，使用了设计模式的程序就好像拥有了无上的法力。本人见到很多的人在自己的博客中详细的讲解各种设计模式的使用场景和使用方法。本人觉得这些文章虽然给不了解设计模式的人员加深理解和学习的机会，但是同时也给更多的初学者一种误区！

下面就来详细的说明这些误区：

一、过度设计

设计模式提倡的是面对变化，产生变化时能够对变化及时的进行修改。这里指的修改是添加新的代码来完成变化的功能，而不是对原有的代码进行修改。但是更多的时候，我们面对的变化是我们并不知道的，如果我们可以预测变化，这还叫变化吗？既然我们不知道或者说不能确定变化在那里，我们怎么可能知道要使用哪个设计模式呢？而教我们使用设计模式的文章里面更多的是已经存在的需求称为变化（这个变化是自己预测的，或者根本就是需求），然后使用在这个预测下所要使用的设计模式。
咋一看，挺玄乎的，确实厉害。那我们来看看这样的代码最后会产生的结果：

一、可能我们预测的变化根本就不存在，那就是明显的过度设计；

二、设计有存在的必要，但是对现有系统的其他变化产生了不利的影响；

三、现实的变化超过了现有设计的范围，需要重新设计；

而出现以上三点比你的预测命中的几率可能是1/10，甚至更低！

那显然我们想当然的去预测使用设计模式并不是万能药，那要怎么样去解决呢？遵循敏捷开发的一些原则：简单—尽量减少工作量是至关重要的；我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户需要。保证客户需求的情况下最简单的实现方式，不去做一些多余的预测和臆测；通过和客户软件不停的使用后持续的改进软件。

二、一步到位的思想

很多人在设计一个软件的时候，总喜欢想得大而全，包括我自己也有这样的想法（虽然我时刻告诫自己这样不好）。而现在设计模式刚好貌似是拯救这个思想的救命稻草，因此太多的人觉得我使用上设计模式，以后就可以随意的扩展自己的程序，这样不是很好吗？我一开始也觉得这简直太棒了，我努力的学习设计模式来达成这个梦想。

我们再来看看现实：我们的程序是在有限时间内完成有价值的软件，而不是包治百病的万灵贴。扩展是有代价的，要确保这个方面的扩展就需要舍弃另一方面的功能，这是一个矛盾体，而往往这样的矛盾体是最难抉择的。当你的程序内存在成百上千个这样的抉择，可想而知会有多么的郁闷（这大概就是人月神化里面提及的“第二项目”）。那我们的解决方式就是遵循敏捷开发的一些原则：经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。更快的把软件推向客户，当然是可以使用的软件，而不是次品；由用户的使用反馈来决定是否需要扩展；这样的目的性更加明确，更加有效。

三、数据库设计和程序设计的冲突

个人感觉这个是大家无法使用设计模式的最大障碍！现阶段的数据库都是基于关系型的数据库，也就是说我们设计数据库都是符合范式的约束的。但是程序的设计是面向对象的设计思路，两者的差别是显而易见的。我们就拿一个可以扩展的系统来说，我为了增加一个功能，对于数据库设计来说最为主要的历史数据和性能，而对于面向对象的程序设计则不是如此，是扩展性和继承性。很显然我们会为了系统的性能和对历史系统数据的保护，牺牲掉程序的扩展。我们又有多少的系统是独立于数据库开发程序的呢？

从以上角度来看，设计模式并没有想象的这么好，你可以使用它来扩展你的程序（大型的程序上尤为重要），而对于一些中小型的程序来说并没有处处使用的必要。当然以上言论不是让大家不要学习设计模式了，而是让大家把眼界放宽，不要为了设计模式而设计模式，就像几年前的ajax一样。

估计这样的帖子会有很多的人不认同把，请悠着点，还有不欢迎说脏话的。我们只谈技术！