设计模式的一点看法

rel="File-List" href="file:///C:%5CUsers%5Clizl%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml"> rel="themeData" href="file:///C:%5CUsers%5Clizl%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> rel="colorSchemeMapping" href="file:///C:%5CUsers%5Clizl%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">

    记着有句话这么说来者：设计模式是程序员的内功修养。

笔者陆陆续续买了些模式方面的书。记得看完GOF的 模式的书后，感觉一片茫然，不知所云。在经历了的代码实践后，对对象的看法有了很大的感知。这时候我又拿起的模式的书，突然发现自己和的大师的思想接近了，于是呼，编码的时候总是喜欢往某个模式上“靠”，但是，工作的效率下降了很多，项目经理开始报怨了。之后，做些了设计工作，面向对象的理解又提高了些，需要考虑软件的可扩展性和维护性，有些时候能不知觉的使用些模式。这就能说掌握模式了么？有次BEA论坛，有人说了句“没有10年开发经验不要谈模式”。看来模式的学习是个反复迭代过程，没有所谓的“精通”，只是每个人理解层次的差异罢了。

所以：

1，  模式的学习需要反复，在日常的设计编码有意识思考模式。

2，  面向对象是理解模式的基础。而面向对象的理解不是一蹴而就的，需要经过大量代码的编写（简单的认为10万行代码还是必须的）

3，  阅读代码是个很好的学习手段，尤其在java领域，开源框架很多。找些优秀框架读读会受益无穷。

4，  Design 和 Coding 的区别很大.。只有做些设计工作才能有模式实践的机会。

5，  模式也不是万能药。一个模式有他的适用背景。迷恋设计模式的人很容易犯上过渡设计。

附：

面向对象几个原理：

开闭原理(OCP)： software entities should be open for extension, but closed for modification.

                            （策略模式很能说明这个意思）

里氏代换原则（LSP）：父类能代替子类，反之不可

接口隔离原则（ISP）:使用单一的接口，降低对其的依赖。

依赖倒置原则（DIP）：依赖抽象，不依赖具体

合成/聚合原则（CARP）多用合成/聚合，少用继承。

迪米特原则(LoD)：一个类的设计应该尽量简化，尽量保持其单一性，并较少和外界联系。