漫谈设计模式–前言

2014/03/25

本文原创作者:Cloud Chou. 欢迎转载,请注明出处和本文链接

最早接触设计模式还在大四的一个课题设计时,有同学从校外实习回来,告诉我设计模式很牛逼,然后告诉了我什么是单例模式,就是说保证程序里类的实例只有一个,当时我想我设计的程序,某些类也只有一个实例,是不是就意味着我使用了单例模式呢,他笑了,说这根本就不是单例模式。那会我是在client处只创建了某个类的实例,用来与数据库交互,创建dto对象。然后答辩时,我就说我用到了单例模式,现在回想起来也觉得确实好笑。

读研的时候,学校开设了专门的设计模式课程,当时觉得设计模式很牛又深不可测,又特别神秘,于是便报了这门课程。给我们教书的是一个华裔美国人,他当时给我们讲,我们一个师兄在北京某个公司里,用设计模式给公司带了很大的价值,并成功地走上了架构师之路。我当时想,设计模式好厉害,好像什么问题都能用它解决,当时非常崇拜设计模式。但是虽然系统地学习了设计模式,但是学完之后还是觉得云里雾里,现在想想,主要原因还是没有做过实际项目把。

10年找实习公司那会,我看了大话西游设计模式,里面谈到了如何用策略模式实现计算器。当时柯达公司过来招聘,需要上机考试,其中有一个题正好是计算器,然后我就用策略模式做了实现,得到面试官的欣赏,后来也就进了柯达实习。实习后开始接触实际的Android项目,当时对OOD感觉非常困扰,设计类的时候甚至不知道设计成只有静态方法的工具类还是普通的类,当时可能更多的还是面向过程编程的思维把。

11年年底找工作前夕,当时觉得很多公司应该特别重视设计模式,偶然在网上看到了别人发的关于设计模式的博客,感觉写得特别好,浅显易懂,讲了很多实例,真正做到了与实际项目结合,并讲出了设计模式的本质,还讲了设计模式的各种变形以及如何结合使用,受益匪浅,博主后来出书了,《研磨设计模式》,我便买了这本书,好好地学习了一番,当时能基本看懂每个设计模式,但是终究还是缺了实际应用。后来找工作时才知道自己方向错了,公司多只重视算法,并不怎么重视设计模式。

11年年底正式参加工作,做项目时,也用到了一些设计模式,比如单例模式,访问者模式,模板方法模式,职责链模式,观察者模式,期间也看了Android的一些源代码,看到它对设计模式的灵活运用,对设计模式有了更深刻的理解。

有不少人对设计模式不屑一顾,认为只要遵循面向对象的设计原则,就可以让程序拥有很好的扩展性和可维护性。我觉得面向对象的设计原则更多是一种指导思想,没有提供具体的解决方案,而有了设计模式,很多时候只需要套用一下 ,就能让程序有了更好的扩展性和可维护性。软件开发人员相互交流的时候,只使用设计模式的名称,便可知道程序的大致模样。理解了设计模式之后,再去看其他人写的源代码,比如说一些开源框架源代码,理解起来更容易,而不是在方法调用之间跳来跳去,最终也不知道整个源程序的逻辑结构。我们看到某个类的命名,可能就知道他使用了什么设计模式,也就知道了类之间的关系,比如说Android源代码里的AlertDialog.Builder,就使用了生成器模式。

经过这几年工作后,又重读了一遍《研磨设计模式》,对设计模式的使用时机有了新的体会。刚开始工作时,总觉得这也应该留下扩展的方式,那也应该留下可扩展的方式,陷入了滥用设计模式的境地。现在的经验是项目初期,一般都需要赶进度,否则项目存活下来都困难,更不用去谈什么扩展了,因此应尽快地赶项目,而不是考虑扩展方式。等到Demo版本出来后,流程都可以跑通了,这时候再看项目哪些关键点需要扩展,优化,重复代码多,这时候再重构。当然如果你对这个项目涉及的业务非常熟悉,你知道哪些地方需要扩展,哪些地方是不变的,你可以在项目初期就设计好大框架,然后再去实现,小处也可在后期重构。

¥打赏5毛

取消

感谢您的支持,我会继续努力的!

扫码支持
赏个5毛,支持我把

打开支付宝扫一扫,即可进行扫码打赏哦

本篇目录