工作三年,对于设计模式的一点看法

        首先,我得承认自己在设计模式的修炼上还仅仅只是刚刚踩上登山的石阶,抬头望去,山腰还十分遥远,山顶更是远在实现之外。


        工作满了一年那会,看到不少人在讨论和学习设计模式,于是乎,随大流的买了一本《Head First 设计模式》,花了一个月左右,把它看完了。这确实是一本不错的入门书。看完之后,跃跃欲试,挺想把设计模式用到工作中的,但是想起书上反复提到的不要滥用设计模式,为了模式而模式,所以在纠结中,把好些个类做成了单例模式(好吧,这几个单例做得没什么坏处,但是也没多少好处,仅仅是为实例提供了一个全局访问点,方便了编程,不用记得把实例传来传去罢了),之后,就渐渐淡去了对设计模式的兴趣,没有在上面花多少力气。


        之后的这两年里,虽然不曾刻意的使用,但是简单的工厂方法,组装模式,单例模式,观察者模式等也不时出现在我的工作代码中,使用的时候没有想太多,自然的也就用了。的确,这些模式帮助我以更加清晰的逻辑去构建我的代码,但是,如果问我用了这些模式有什么好处,似乎也说不上来,用了也仅仅是因为其他似乎也没有什么更好的办法。


        也曾经在一些demo等代码中,遇到过一些设计模式使用的绝佳案例,读到的时候真的觉得这个模式有种“舍我其谁”的精妙感,看似简简单单的一个模式,但是真的有中化腐朽为神奇,画龙点睛的感觉,深深觉得自己差得好远好远。


         我们使用设计模式的目的很多,为了更好的可维护性,更好的可扩展性,更好的可移植性,但是归结到两个字,就是重用。使用设计模式是存在成本的,时间、代码量甚至是程序的性能。尤其是,当项目基本成型之后,设计模式使用的成本就更加明显,除了以上的成本意外,还有因为修改引入新的bug的风险。


          这里插入点插曲:个人觉得,从性能来说,尤其是时间性能来说,原始的面向过程编程(OPP)始终是性能最高的。但是,一份好的面向过程的code,对于开发者的能力要求比较高(即较高的人力成本),开发周期也比较长(较高的时间成本),加之计算机的性能增长和成本的降低,使面向对象编程(OOP)更加符合目前商业开发的需求,所以OOP大行其道。这和java和C#这些语言慢慢侵蚀C/C++的市场份额是一样的,无非是设备提供了更高的性能来让语言“浪费”而已,不过,整个项目而言,项目整体成本的降低使这些“浪费”变得物有所值。


        言归正转,既然设计模式是一种成本,那么,仅当设计模式达到它的目的——重用的时候,设计模式的使用才是利大于弊的,否则弊大于利。


         那如何做到重用呢? “封装变化”这一条相当之重要。很多设计模式都深切的表达了这条原则:

         策略模式,简言之,就是封装了行为,因为行为在变化。

         状态模式,就是封装了状态,因为状态在变化。

         命令模式,就是封装了命令,因为命令在变化。

          观察者模式,封装了观察者和被观察者,因为需要感知变化的观察者在变化。

          迭代器模式,封装了容器,因为容器在变化。

          ......

         使用设计模式的时候,我们就是要找到系统中现在或者未来变化的点,把变化封装起来,这样,我们才可以做到“向修改关闭,向扩展开放”,才可以做到“针对接口编程,不针对实现编程”,才可以做到“松耦合设计”;只有封装了变化,我们才能让我们才能够让新的变化到来的时候,原有的代码可以继续工作,而不需要重写,这才是重用。


         可以说,封装变化是一切的开始,但是,捕捉变化的能力,是需要经验去积累的,没有足够的项目经历,很难猜测系统未来会发生何种变化。如果瞎猜,封装了不会变化的因素,那么,当变化到来的时候,你会发现,你准备的接口都没能用上,这样使用设计模式所带来的成本就无法收回,我们就“吃亏”了。


        所以,在条件成熟之前,不要急于使用设计模式,否则偷鸡不成蚀把米。一个用不好设计模式,确成天把设计模式挂在嘴边,用在项目中的程序员,远远比一个不知设计模式为何物的程序员可怕的多。


        

        写给未来的自己,希望一两年后,再看这篇文章的时候,能够有更深的体悟,能够意识到自己的进步。


         


没有更多推荐了,返回首页