设计模式在编程中有重要的指导意义，每个项目在架构阶段就应该很好的满足设计模式的六大原则，当然也要根据项目的实际情况来权衡取舍，平衡效率跟质量的关系。下面简单介绍下设计模式的六大原则。

1.单一职责原则

a）Single Responsibility Principle，简称SRP。这个原则是存在争议的，就是每个类的设计到底是“单一职责”还是尽可能的承担更多的“职责”？这个问题我觉得应该就项目的实际情况来决定，比如项目规模比较大，就应该把“职责”拆分的更细，这样可扩展性就会增加，同样的工作量会增加，在使用上可能需要的条件更多。简单的举个例子就：类的属性跟行为，如果分开，完成一件事情就要属性跟行为的不同接口结合到一起来实现，但是每个类的功能会很清晰。单一职责原则要求一个类只有一个原因引起是改变，我个人认为关于这个“尺度”其实可以根据实际情况来操作，可以是多于一个原因。

b）单一职责的好处有哪些呢？我们可以总结一下，不防结合上面“属性跟行为”的例子：

*类的复杂性降低了，实现什么职责都有清晰明确的定义（我只负责一件事）。

*可读性提高，这个是复杂性降低的必然结果。

*可维护性提高。

*变更引起的风险降低了，程序的变更是必不可少的，变更一个功能只需要修改一个接口就可，对其他的没有影响，对系统的稳定性、可扩展性、维护性都很大的帮助。

2.里氏代换原则

a）在面向对象的编程语言中，继承是必不可少的、非常优秀的语言机制。

优点是：

*代码共享，减少创建类的工作量，每个子类都拥有父类的方法用途属性。

*提高代码的重用性。

*子类形似父类又异于父类。

*提高代码的可扩展性，通过继承父类来扩展父类的功能。

*提高产品或者项目的开放性。

缺点：

*继承是侵入性的，只要是继承就必须拥有父类的所有属性与方法。

*降低代码的灵活性。

*增强了耦合性。

因为继承的这些有确定，下面我们引出解决方案：里氏代换原则，Liskov Substitution Principle。里氏代换原则为继承定义了一个规范，包含四层含义：

*子类必须完全实现父类的方法。

*子类可以有自己的个性。

*覆盖或者实现父类的方法时输入参数可以被放大。

*覆盖或者实现父类的方法时输出结果可以被缩小。

b）里氏代换原则的目的就是增强程序的健壮性，及时版本升级也可以保持良好的兼容性。

3.依赖倒置原则：

a）Dependence Inversion Principle。其原始定义包含三层含义：

*高层模块不应该一览底层模块，两者都应该依赖其抽象。

*抽象的不应该依赖细节。

*细节不应该依赖抽象。

具体在Java语言中的表现：

*模块间的依赖通过抽象发生，实现类之间不直接发生依赖关系，依赖通过接口或者抽象类来实现。

*接口或者抽象类不依赖实现类。

*实现类依赖接口或抽象类。

其实更加简洁的定义就是面向接口编程OOD（Object-Oriented

Design）的精髓之一。

4.接口隔离原则

a）接口隔离原则的定义：客户端不应该依赖其不需要的接口，类间的依赖关系应该建立在最小的接口上。简单理解就是，客户端应该以来其需要的接口，不需要的接口要剔除掉，也就是你依赖的接口的方法对于客户端来说应该是都有用的；最小的接口也就是要求接口细化，接口纯洁。b）接口隔离原则对接口进了规范约束：

*接口要尽量小，对于“小”也是有“尺度”的，需要自己把握。

*接口要高内聚，提高接口、类、模块的处理能力，减少对外的交互。

*定制服务，一个系统或者系统内的模块必然会有耦合，既然耦合，就要有相互访问的接口，所以设计时就需要为每个参与者定制服务。

*接口设计是有限度的，这个就是权衡接口的规模跟结构复杂度的关系，保证灵活性、开发难度、可维护性在接受的范围内。

5.迪米特法则

a）Law of Demeter，也称为最小知识原则（Least

Knowledge Principle）：一个对象应该对其他对象有最少的只是了解。通俗的讲，一个类应该对自己需要耦合或者调用的类知道的最少。

b）迪米特法则对低耦合提出了明确的要求：

*只跟朋友交流，如果学过UML的话，应该知道，对象之间的耦合，存在组合、聚合、依赖等关系。

*朋友之间也有距离，具体的讲，一个类的public属性或方法越多，修改时涉及的问题就越多，变更引起的风险扩散也就越大。要将public的属性或者方法降到最低。

*是自己的就是自己的，如果一个方法在本类中接不增加类间关系，也对本类不产生负面影响，那就可以放置在本类中。

*谨慎使用Serializable，这个问题实际中出现很少，就是客户端与服务端通信是属性权限影响序列化的问题。

6.开闭原则

a）开闭原则是Java世界里最基础的设计原则，这指导我们如何建立一个稳定、灵活的系统。开闭原则的核心定：对扩展开放，对修改关闭。

b）开闭原则的重要性

*开闭原则对测试的影响，有变化时，原有健壮代码不修改，通过扩展实现变化，这样已经测试过的部分就不要再测试。

*开闭原则可以提高复用性

*开闭原则可以提高可维护性

*面向对象的要求。

c）开闭原则的实际使用：

*抽象约束，通过接口或抽象类约束一组可能变化的行为并能实现对扩展开放。

*元数据控制模块行为，元数据，metadata，也就是配置参数，这样可以减少重复开发，也就是很多参数可以是服务端提供的。

*定制项目章程，对于项目而言，约定由于配置。

*封装变化，将相同的变化封装到一个接口或者是抽象类中；将不同的变化封装到不同的接口或抽象类中。

PS：如有谬误欢迎指正！