我才开始学程序的时候,觉得设计模式是个很炫的东西,一写程序就一定要照本宣科的用上各种模式。现在才感觉其实设计模式是在程序复杂到不能管理的时候,没有办法的办法。就像是城市修地铁,修高楼一样。我们也许会觉得一个城市有很多地铁,有很多高楼,这就是个NB的城市。其实这是因为城市人太多,太大已经让人的生活有困难了,不得已费神费时的修地铁,高楼。
设计模式根本上是把各种简单的操作复杂化了。比如单例模式,其实是静态类的复杂化;工厂模式,其实是new函数的复杂化。以前一个static,一个new就能搞定的东西,用了模式后,就成了一大段一大段错综复杂,隐晦的代码了。
做架构的时候鼠目寸光肯定是不行的,但更多的要注意不能好高骛远。要坚持一种够用就行的态度。一段代码,如果感觉以后最多重复2,3次使用,就不要把他合并成函数或者使用其他模式。就算是以后真的重复代码变多了,那也只不过是处理2,3处的地方。毕竟我们不能把一个系统所有细节以及未来的需求变动看清楚,所以一开始就力求做一个大而全的架构是不现实的。一是难以找到下笔处,二是长时间花在没有结果的,空洞的架构工作上,也很伤热情。
其实比起大而全的架构,一步一个脚印的,把程序从小做大更为重要。经常我会犯一口气吃成胖子的错误,因为有的中间过程要写一些临时代码才能测试,所以想一口气把整个过程写完再测。但其实最后程序的问题可多到我们不能应付。
其实这也照应了一句话,所有模式都是为细节服务。只有在明确有了某种模式的需求后,才能去使用模式。这种需求即使是在发现程序有些不好管理后才提出也是很正常的。反之则是像国内随心所欲的修建各种公共设施,结果很多设施修好后,根本就没有使用的需求。
其实模式这东西,真的理解得很透了后。是可以根据实际情况作各种更改的,到最后有可能根本看不出是使用的何种模式。对模式理解得越透,在实现模式的时候就越不需要使用那些隐晦的技法。这和搞学术研究一样,对一个理论理解得越深,就越不需要深奥难懂的数学来支撑。模式用得好不好,不在于对模式实现的算法背得多熟,而在于能不能只在不得不使用的时候才使用。