一、前言

设计模式关乎了代码的可扩展性和可维护性，在开发过程中具有重要的江湖地位。此次仅讨论关于七大原则（有的地方是六大原则，稍后说区别）的问题。

二、七大原则的基本概念

设计模式有七大原则，分别是：①单一职责原则，②里氏替换原则，③合成/聚合复用原则，④依赖倒转原则，⑤接口隔离原则，⑥最少知识原则，⑦开闭原则。有的地方把组合/聚合复用去掉称作六大原则，个人认为组合/聚合复用对于一个类的构建还是很重要的，应该加上。

三、七大原则的理解

1、单一职责原则

概念：就一个类而言，应该仅有一个引起它变化的原因，即一个类只负责一项功能。

我认为不仅仅对于类，同样对于方法或者模块，也应当遵守单一职责原则，即一个方法负责一个功能。

例如一个类中有制作饺子的方法，该方法应该只负责组合买韭菜、擀皮、包饺子等多个方法，而不是直接在制作饺子的方法中写具体步骤，这样有利于改变其中某个步骤时不影响其他步骤。同样一个类也只负责一项功能，则制作饺子类应当只负责组合步骤，具体每个步骤应当是独立单一职责的类。步骤类可以通过new或者组合（不推荐使用new，之后的组合/聚合复用原则会讲为什么）的方式加入制作饺子类。

2、里氏替换原则

概念：子类型必须能够替换掉它们的父类型。

遵守该原则的方法是在继承类时，除了扩展一些新的功能之外，尽量不要删除或者修改对父类方法的引用，也尽量不要重载父类的方法。

如果违反该原则，会大量重写父类中的方法，降低代码复用性，反映出了父类构建的不完善，将子类的特有方法写在了父类中。

3、合成/聚合复用原则

概念：尽量使用合成/聚合,尽量不要使用类继承。

合成和聚合是通过将需要使用的方法形成新的对象，将对象通过set方法注入类的属性，来达到类调用需要使用的方法。

通过合成，可以灵活的改变类需要的方法（此时属性声明为包含所需方法的接口类，后面依赖倒转会讨论），实现较少的修改类，而对类进行扩展。

4、依赖倒转原则

概念：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

依赖一般是指将对象传递给方法。此处理解为将对象传递给属性也应当称之为依赖。即在一个类中使用其他的类，不应当直接使用其他类的实例化对象，应当使用其他类的抽象，然后通过注入或者传递的方式来使用具体实例化类。

通过该原则，可以实现较少的修改类，而是通过不同的注入实现不同的功能。该处使用了抽象的概念，记得我一开始对接口有什么作用很不理解，在学习这个地方是对接口的作用有了深刻的理解。

5、接口隔离原则

概念：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

当一个类（a）对另一个类(b)依赖时，如果不遵循该原则，则引入的对象不仅需要实现类a需要的方法，同样需要实现类a不需要的方法，此时增加了代码冗余，需要对以来的接口进行分割，将需要的方法和不需要的方法分成两个新的接口，实现接口隔离。

6、最少知识原则

概念： 如果两个类不必彼此直接通信，那么这两个类就不应当直接的相互作用；如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

该处主要思想是尽量减少类与类之间的调用，包括方法的调用和属性的调用。例如两家店，餐饮店和奶茶店，当顾客需要两家的菜单时，应该两家自己提供自己的菜单，而不是奶茶店将菜单给餐饮店（餐饮店调用奶茶店的菜单），然后餐饮店一起给顾客。这里分别提供，因为从客观上餐饮店和奶茶店并没有联系，但是顾客需要菜单，因此顾客可以调用两家的菜单。

遵守该原则，可以较少两个类的耦合性，修改其中一个类不会影响另一个类。

7、开闭原则

概念：类、模块和函数应该对扩展开放，对修改关闭。

该原则贯穿以上六个原则，以上六个原则的最终目的就是实现开闭原则。实现了开闭原则，则对于代码维护和扩展具有很大的好处。

四、结尾

如果在编程中可以遵守七大原则，则程序的可维护性和可扩展性可以大大提高。同时，设计模式还有23种经典模式，经典的模式是实现七大原则的经典方法，是前人经验的总结和智慧的结晶，如果可以好好礼用，可以进一步提高程序的可维护性和可扩展性。

我觉得一开始可以只接触遵守七大原则，不需要盲目追求23种设计模式，当对于七大原则有较好的理解并使用时，可以再进一步学习经典的设计模式。