尽量在不得已的情况下才使用设计模式

我才开始学程序的时候，觉得设计模式是个很炫的东西，一写程序就一定要照本宣科的用上各种模式。现在才感觉其实设计模式是在程序复杂到不能管理的时候，没有办法的办法。就像是城市修地铁，修高楼一样。我们也许会觉得一个城市有很多地铁，有很多高楼，这就是个NB的城市。其实这是因为城市人太多，太大已经让人的生活有困难了，不得已费神费时的修地铁，高楼。

设计模式根本上是把各种简单的操作复杂化了。比如单例模式，其实是静态类的复杂化；工厂模式，其实是new函数的复杂化。以前一个static，一个new就能搞定的东西，用了模式后，就成了一大段一大段错综复杂，隐晦的代码了。

做架构的时候鼠目寸光肯定是不行的，但更多的要注意不能好高骛远。要坚持一种够用就行的态度。一段代码，如果感觉以后最多重复2,3次使用，就不要把他合并成函数或者使用其他模式。就算是以后真的重复代码变多了，那也只不过是处理2，3处的地方。毕竟我们不能把一个系统所有细节以及未来的需求变动看清楚，所以一开始就力求做一个大而全的架构是不现实的。一是难以找到下笔处，二是长时间花在没有结果的，空洞的架构工作上，也很伤热情。

其实比起大而全的架构，一步一个脚印的，把程序从小做大更为重要。经常我会犯一口气吃成胖子的错误，因为有的中间过程要写一些临时代码才能测试，所以想一口气把整个过程写完再测。但其实最后程序的问题可多到我们不能应付。

其实这也照应了一句话，所有模式都是为细节服务。只有在明确有了某种模式的需求后，才能去使用模式。这种需求即使是在发现程序有些不好管理后才提出也是很正常的。反之则是像国内随心所欲的修建各种公共设施，结果很多设施修好后，根本就没有使用的需求。

其实模式这东西，真的理解得很透了后。是可以根据实际情况作各种更改的，到最后有可能根本看不出是使用的何种模式。对模式理解得越透，在实现模式的时候就越不需要使用那些隐晦的技法。这和搞学术研究一样，对一个理论理解得越深，就越不需要深奥难懂的数学来支撑。模式用得好不好，不在于对模式实现的算法背得多熟，而在于能不能只在不得不使用的时候才使用。