• 单一职责原则

    此原则为如何定义接口提供了建议，原则的内容：只能有一个原因引起接口发生变化。听起来比较抽象，具体点儿讲就是接口中不应定义多个逻辑不相干的抽象方法，此原则的重点在于如何区分职责，一旦职责区分清楚，则接口就很容易定义，java底层很多接口的设计都是只有一个方法，这也是符合单一职责的原因吧。

• 里氏替换原则

    此原则为如何定义继承关系提供了建议，原则内容：所有引用基类的地方必须能透明地使用其子类的对象，通俗点讲， 只要父类能出现的地方子类就可以出现， 而且替换为子类也不会产生任何错误或异常， 使用者可能根本就不需要知道是父类还是子类。 但是， 反过来就不行了， 有子类出现的地方， 父类未必就能适应。在继承关系中，子类的功能要大于父类，当重载(overload)父类方法时，参数类型要大于父类，返回值类型小于父类。

• 依赖倒置原则

    此原则核心是面向接口编程，即要依赖抽象，而不是具体实现。属性以及方法的参数的类型尽量是接口。

• 接口隔离原则

    此原则中的接口不单单是指类接口（interface）还包括实例接口（Object interface）。原则的内容：客户端不应该依赖他不需要的接口，或者是类间的依赖关系应该建立在最小的接口上。当相同业务逻辑接口提供给不同客户端使用时，不同客户端所能访问到的接口应该用权限加以限制，接口应该只暴露客户端需要的方法。

• 迪米特原则(最少知识原则，LKP)

    此原则对实现类之间的低耦合提出了建议。原则的内容为：一个对象应该对其他对象有最少的了解。当一个类A需要调用另一个类B的一个功能时，此功能如果能用一个方法完成就不要在B中暴露两个方法给A，因为B暴露给A的方法越多，A、B两个类之间的耦合度就越高。另外A类应该只和B直接关联，如果此功能还需要另外的C类，那么C类不应该和A发生关联，B类和C类直接关联就好了。

• 开闭原则

    此原则指导我们如何建立一个稳定、灵活的系统。原则内容：一个软件实体如类、 模块和函数应该对扩展开放，对修改关闭。从原则内容至少能解读出来两方面的内容，第一：当原有需求发生变更，如果能通过扩展来应对需求变更就不要修改原有的代码。第二：当我们设计一个功能时给以后扩展此功能留出后路。

本文出自 “埃文” 博客，请务必保留此出处http://wenshengzhu.blog.51cto.com/5151285/1853095

设计模式之六大设计原则