最近看了两本关于设计模式的书,在此记录一下感想。
第一次听说设计模式是在网上查询MVC模式的时候,顺便搜了一下设计模式,才了解到武林中存在着“23种设计模式”这么个东西。当时以为觉得设计模式就是倚天剑、屠龙刀,一个代码写的很烂的菜鸟看了设计模式就会成为“武林至尊”,代码水平立刻变得很厉害。学习了之后才知道我想错了,设计模式只是倚天剑和屠龙刀中的“九阴真经”,就算得到了还是要苦苦练习,结合实际的编程和项目才能够把其中的思想融会贯通,真正成为一个编程高手。
“设计模式”是一套被反复利用、被多数人知晓的、被无数工程师实践的代码设计经验的总结。因为它比较抽象,没有一定编程经验很难读懂,更不能理解其精髓。23种设计模式总体看下来,有的当时就能理解,有的需要思考一番才能理解,就像以前不会的很难的那种数学题,看了答案,跟着答案的思路捋一捋就理解了,然后下次遇到类似的题稍微变一变又不会做了。这次初探设计模式也是一样,合上书之后自己写代码,很难想到该怎么将刚学到的设计模式用到自己代码中去,或许这就是经验太少的原因吧。
我最大的感受就是单一职责原则、开放封闭原则、依赖倒转原则、里氏代换原则、迪米特法则、接口隔离原则这六大设计原则比设计模式更加重要,如果说设计模式是面向对象编程的编程思想,那么设计原则就是这些编程思想的指导总纲,而这六大设计原则的目的又可以概括为六个字,就是“高内聚,低耦合”。(感觉看完书我就记住了这六个字)高内聚就是说,设计的接口内部功能要单一紧凑,不要想起什么都往里面塞,最后搞的非常臃肿,没有办法复用。然后低耦合是说,设计的接口之间的关联要尽量小,不要出现更改一个地方的时候牵一发而动全身,几十个地方都要跟着改,要不就没法用。说起来我们学习设计模式的最终目的就是要实现代码的最大化复用。
单一职责原则:一个类只负责一项功能或相似的功能,承担尽可能少的职责。这样可以增强可读性,方便维护和修改,当然缺点就是在小的项目里运用会显得拆分的太详细,类的数量会急剧增加。(然后就想着反正是小项目没必要考虑单一职责原则,然后后后来项目的功能越加越多,又变成了又臭又长的烂代码。。。)
开放封闭原则:类、模块、函数等对扩展开放,对修改封闭。增加一个功能时,应当尽可能的不去改动已有的代码,当修改一个模块时不应该影响到其他模块。(这个相信大家不能同意更多,因为谁也不想让原来跑的好好的代码经过自己的手之后,出现各种奇怪的问题,所以不会去想动以前的代码。问题是根据我的经验,由于“已有”的代码在设计的时候没有考虑“低耦合”,导致改动的时候牵一发而动全身,不得不去动已有的代码。。。)
里氏替换原则:所有能引用基类的地方必须能透明地使用其子类的对象。只要父类能出现的地方,就可以用子类来替换它,反之,子类能出现地方父类不一定能出现,因为子类拥有父类的所有属性和行为,但是子类拓展了更多的功能。子类重写父类方法的时候功能不能改动太多,功能实在差很多的话就不要重写了,应扩展一个新方法,这一点我做的很不好。
依赖倒置原则:高层模块不应该依赖低层模块,二者应该依赖其抽象。把具有相同特征或相似功能的类,抽象成接口或者抽象类,让具体的实现类继承这个抽象类。抽象类(接口)负责定义统一的方法,实现类负责具体功能的实现。
接口隔离原则:用多个细粒度的接口来代替由多个方法组成的复杂接口,每一个接口服务于一个子模块,不要试图建立一个很庞大的接口供所有依赖它的类调用。这其实还是强调“高内聚”的事儿。
迪米特原则:一个对象应该对其他对象有最少的了解。对象与对象之间应该使用尽可能少的方法来关联,避免千丝万缕的关系。这其实还是强调“低耦合”的事儿。
设计模式在编程中的作用,就像《孙子兵法》在战争中的作用。设计模式是前辈们归纳总结出来的指导思想,对设计模式的运用不能纸上谈兵,丰富的项目经验是很重要的。不同的阶段来看看这些理论,会有不同的收获。这次只是初探,随着以后的代码写的越来越多,还要随时注意学习和运用这些设计模式。