设计模式的一些瞎想

    最近面临就业压力。了解到面试的时候会问到些设计模式的东西。赶紧临时抱一下佛脚。说来其实我一年多以前就看过程杰的《大话设计模式》当初看的时候觉的写的挺生动的。因为是为了初学者更好的理解，所以就讲的比较浅，但我当时就真的浅浅的看了一遍就没管了。觉得也就是那样，之后自己编码的时候根本就想不到那儿去，更别谈用了。

    说实话，就像很多人说的那样，如果没有一定的代码量的话，看一些概念性的设计是吸收不了的。在我身上也的的确确是这样的，当年囫囵一遍，就把书丢了，从此再没拾起，除了名字也的确没有吸收到任何东西。如果你有了一定的代码量的积累，走过工程中的不少前人走过的弯路，可能会更加从设计的角度来理解为什么会出现这样的设计，这样的设计是为了解决什么样的问题。设计模式说白了是个什么玩意儿？

                                      就是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结！

为了提高代码的复用性，为了提高可维护性，为了实现工程的本质------让重复的工作被机器代替。一切的一切都是为了偷懒。。。

    所以提倡不要重复造轮子，提倡高内聚低耦合。

    所以说设计模式的本质在于抽象,用抽象隔离变化,用抽象分解复杂事物为一个个单一职责的个体.

也就是个体的倡高内聚低耦合然后再组合或组装到一起完成职能.

 

思路是很直观的,对设计模式的误用往往在于,过度分解造成组装结构上的复杂性和难以理解.

所以要在分解和组装上达到一个平衡.

 

最后呢，设计模式其实就是那5个原则。而这几个原则也都是为了达成高内聚，低耦合而被提出的。

1.开放闭合(Open Closed Principal，OCP)：模块应对扩展开放，而对修改关闭

2.里氏代换原则（LSP）：如果调用的是父类的话，那么换成子类也完全可以运行

3.依赖倒转原则（DIP）：抽象不应该依赖于细节，细节应当依赖于抽象。要针对接口编程，而不是针对实现编程。

4.单一职责原则（ SRP）：一个类，只有一个引起它变化的原因。应该只有一个职责。（变化的原因就是职责）

5.接口隔离原则（ISP）：定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干

6.迪米特法则（LOD）：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。