我眼中设计模式的六大原则

设计模式有六大设计原则，每种 设计模式 都都绕不开这六个原则。

单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。

这个原则讲在类（接口）的设计上，一个类所承担的职责一定要单一。但实际中，职责粒度的划分是很不明确的，没有绝对的到哪一粒度就算是满足单一了。反之，过度的考虑单一职责，会引起类的剧增。所以并不必拘泥于类的单一职责，不过于复杂即可。另外，单一职责也可用与方法设计的考虑，比如一个方法利用传入type加switch的方式，写了大段分支代码，不如拆分方法。

里氏替换原则：子类必须能够替代掉父类。

这个原则看起来想当然，实际使用中药避免一个错误，在父类的业务逻辑中用instanceof判断是否满足子类类型。

依赖倒转原则：高层模块不应该依赖低层模块，两者都应该依赖于抽象。抽象不应该依赖于具体实现，具体实现应该依赖于抽象。

举个实际使用的例，业务层使用底层数据库，如果强依赖于低层实现，那么业务层复用将会十分不便。应该的实现方式是底层用接口实现，上层依赖其接口。典型的例子就是spring+hibernate开发中实现的dao层，而且，hibernate作为orm框架，在努力隔离低层数据库，而spring也用jpa标准，降低对hibernate的耦合，以便能随时替换orm框架。

接口隔离原则：客户端不应该依赖它不需要的接口。

有四层含义

1、接口尽量小，但拆分接口时先满足单一原则，如果已经粒度够小，不必拆分

2、接口要高内聚

3、定制服务

4、接口设计时有限度的，避免过度设计

接口隔离和单一职责全凭经验应用。。。

迪米特法则：最少知识原则。如果两个类不必彼此之间通信，那么这两个类就不应当发生之间的相互作用。

比如A依赖B，B依赖C（A -> B -> C），C的业务逻辑只保留在B中，在A中不应该有C的业务逻辑。这个原则在公司的管理上也是一个道理，经理管理组长，组长管理普通员工。日常各类的各类事务，经理只需要从组长处获取必要信息即可，不需要关心员工的工作细节（特殊事件除外。。），这样就能保证从上到下工作高效，避免过多冗余信息的交换，才是一个健康的组织架构。

开放封闭原则：一个软件实体应该对扩展开放，对修改关闭。

这一点在程序设计中是非常关键的，对于之后可能存在功能扩展的类，做好抽象，设计合理的接口。而类本身的内容尽可能的避免修改，原则是在对类做扩展时，之前依赖此类的地方不需要做任何修改。

即使抛开所有设计模式，能按照上述六大原则进行代码设计开发，代码质量就能得到很好的保证。所有的设计模式不见得一次性都能记住，不用则不熟。但如果能透传理解上面的原则，可能实际写代码中会不自觉就把某一个模式给实现出来了。

设计模式就是一种编程思路，要明白设计模式并不能提高代码效率。曾有大牛提出设计模式是为了解决面向对象的缺陷而存在的，这个观点本人不反驳，但也并不敢苟同好多人认为“设计模式没有存在的必要”。我眼里的设计模式，是 程序员 沟通代码思路的媒介，提高代码可读性与可维护性的工具。如果自己有一天也能达到不自觉就用出了各类复杂的设计模式，到那时，希望自己能在代码中留下“此处用了**模式的思路”，胜过大段的代码注释。