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