我学习设计模式的一些心得

设计模式一直饱受争议,很多人对设计模式推崇备至,但也有很多人认为设计模式误导了编程者,见(《解密“设计模式”》)。

我也只是一个普通的编程人员,这里只能谈一谈我在学习设计模式中的一些想法,不一定正确,欢迎大家谈论。我对设计模式的理解是分阶段的:

一、这是些什么乱七八糟的东西?那时候听到了设计模式的概念,到图书馆借了一本大概名字叫《设计模式初学者入门》之类的书。书里就把23个设计模式 挨个讲了一遍,引用一下每个设计模式的定义,给个类图,配点代码……然后我硬着头皮读完之后,就一个感觉,“脱了裤子放屁”。一个功能,明明很简单、很直 接的就能实现,为什么要添那么多的类,绕那么多的弯?记得当时也就懂了“单例模式”。

二、后来又找其他的书,这时候我读到了程杰的《大话设计模式》,其中用活字印刷的例子,讲解了曹操“对酒当歌,人生几何”的敢动,我仿佛一下子就开 窍了。明白了设计模式,他最重要的目的就是为了应对“变化”。所以回过头来看,为什么之前能懂“单例模式”,就因为“单例模式”的目标很清晰,所以很好 懂;反之,其他的设计模式,目标比较“复杂”,所以我懂不了。

三、但仅仅知道了设计模式的目标,还是没有解决我的疑惑。我记得当时我心里反反复复的一个问题,“有变化,改代码就行了呀。怎么改都是改,为什么就 一定要想你(设计模式)说的那样改呢?”那时候我基本上是单兵作战,代码是自己一个人从头写到脚,哪里有问题我就可以改哪里,完全没有心理负担,呵呵。后 来工作变动,开始了团队开发、维护别人的代码,以及使用第三方组建。我就自然而然的明白了,有些代码,是你只能用不能改的!典型的就是人家只给你一个已经 编译的dll,你怎么改?坑爹呀!所以,那时候,我最先明白的就是Adapter模式,为什么要用Adapter?因为接口不一致,你不使用 Adapter就用不了第三方的代码!

四、如果说上面这个阶段是“迫不得已”的使用设计模式,接下来就是我开始主动的思考和使用设计模式了。我有差不多一年的时间都是在维护公司遗留下来 的老代码——足以让人崩溃的代码!每一次的bug fix,都不得不小心翼翼、如履薄冰,即使如此,仍然有很多次的改动,都是“按下了葫芦浮起了瓢”。让我充分的意识到什么叫“紧耦合”、“坏味道”,我们 会有计划的做一些重构,在这些过程中,我都会主动的思考,能不能套用某种设计模式(但没有一次成功,老大不让,担不起责任呀——系统太老太大太脆弱,你懂 的!呵呵)

五、真正的理解设计模式的核心思想。我认为我目前仍然没有达到这个程度,虽然可以随口说出一些耳熟能详的设计原则,“高内聚、低耦合”,“对扩展开 放,对修改关闭”,“优先使用聚合”之类的。但理解仍然不深,很多时候觉得这也可那也可,拿不定主意。我觉得这是我代码写得太少的原因,需要在更多的实践 中体会提高。

看完这些,你肯定知道,我对学习设计模式是持支持肯定态度的。那么,下面和同学们交流一下学习设计模式的方法吧。

一、实践。记得金旭亮老师曾经说过,“没有写过10万行代码,不要谈设计模式”,可能有点夸张,但道理是棒棒的。比如我,如果没有不得不深入到那些 足够复杂足够混乱的代码,身心饱受摧残,不可能对设计模式的认识有质的提高。因为设计模式的一个重要应用场景,是应付那些复杂的业务逻辑、快速的需求变 化,她的价值在这些地方,才能够清晰的体现出来。“坐而论道”是一种我们都期望的“懒人模式”,但估计很难有效——至少对于我这种资质平庸的人来说吧。

二、明白设计模式的目的。每一个设计模式,一定是要解决一定的问题的;并且解决这些问题是附带了条件的。比如,需求发生了变更,这是问题。如果没有 其他约束,解决这个问题的办法很简单,就是改代码而已,加上一个if...else而已。但是,我们不能这些改!(理解这一点相当重要,切记切记。当然, 你可能会问,为什么不能这么改呢?我们下面再说)我们不能修改类里面的代码,我们只能采取一些其他手段,比如继承、比如封装原有类,来实现新需求。这时 候,设计模式就粉墨登场了。

三、上面所说,为什么不能直接改类里面的方法函数,比如直接加if...else?我们可以从两方面理解。一方面是“被动的”,比如我们是引用的一 个编译了的dll,根本就改不了;或者是团队开发,别人不允许你改他们写好的类。另一方面是“主动的”,接前面“团队开发,别人不允许你改他们写好的 类”,为什么他们不允许你改呢?是不是他们固执、偷懒,没有团队精神?你把官司打到大BOSS那里,可能会被一顿K。你需要仔细的体会,“类”的概念。类 就是一种封装,封装就意味着拒绝修改——想一想为什么会有private关键字吧。好了,就不在这里展开了,不然又要写一本书了。你只需首先明白,设计模式,是一种“带着脚镣的舞蹈”;然后进一步思考,为什么需要这些脚镣即可。(当然,如果你够牛B,这些最终砸碎这些脚镣,不在此探讨范畴)

最后,我还是强调“实践”,如果想要更好的理解第二条、第三条,唯一有效的方法,可能就是实践了(前提是你已经或多或少的研究过设计模式了)。