公用技术——设计模式——设计原则

1、开关原则

　　开关原则的英文是open for extension，close for modification。这个原则主要的目的是为了适应变化。

　　当系统需要新功能时，在不修改原始类的基础上，添加新类对系统进行扩展，从而满足新功能。

　　原则的关键点是为什么不能修改，个人理解有几个以下原因：

1. 由于某些原因，已经无法修改，例如已经使用了很多年的框架，语言API等。
2. 无法评估修改带来的影响，修改之后关联的功能都需要测试，新功能也需要去测试，甚至会导致之前功能产生BUG，这个是最不想看到的。

2、依赖注入

　　依赖注入的同义词有依赖反转，它的英文是Inversion of control，这个原则的核心思想是解耦，它与桥接模式的思想是相似的，依赖抽象而不是依赖具体的实现，将依赖的对象从编译阶段推迟到运行阶段，大大降低了耦合性。

　　解耦的主要目的也是为了适应变化，耦合度低的项目更容易扩展，会极大的降低依赖对象之间的相互影响。

　　原则的关键点是耦合度低的程序比耦合度高的程序有哪些优势，个人理解有以下几点。

1. 降低彼此之间的相互影响，类似于现实生活中的”插拔式”。耦合度高的类似于生活中的”捆绑销售”。
2. 依赖其抽象父类或接口，动态切换子类和接口实现类。新功能通过提供新子类或新的接口实现类来实现，便于扩展。

3、接口隔离原则

　　接口隔离原则的英文是Interface Segregation Principle，这个原则的目的在于client只需要关注自己需要实现的功能，而不是强制去实现所有的功能。

　　它涉及到两种角色，一种是接口规范制定者，一种是client，接口规范实现者。

　　例如在实现某些框架的自定义功能时，只需要重写功能相关的方法即可，而不是接口所有的方法。

　　在JDK8之前，提供抽象类，默认的接口实现类等。在JDK8之后，为接口提供默认的实现。

4、单一职责原则

　　单一职责原则的英文是Single Responsibility Principle，这个原则的主要目的是抽象更贴近实际。

　　在对需求进行抽象时，对象必须切合贴近所抽象事物，明确它的角色，功能，关系等。

　　当对象存在多个职责时，首先会导致对象变的很臃肿，其次会导致重复代码很多，甚至导致整个系统变的很混乱，难以理解。

5、里氏替换原则

　　里氏替换原则的英文是Liskov’s Substitution Principle，Liskov是一位著名的科学家，她提出了该原则：“如果对于类型S的每个对象O1存在类型T的对象O2，那么对于所有定义了T的程序P来说，当用O1替换 O2并且S是T的子类型时，P的行为不会改变”。

　　这句话我个人理解是：当client在调用父类实现某功能时，在创建父类时，从一种子类替换为另外一种子类，不会改变client想要实现的功能，而只是改变了功能的实现方式。

　　原则描述的是两种关系，

　　第一种是父类与子类之间的继承关系，此时父类的职责是子类职责的子集，

　　第二种是接口与接口实现类之间的泛化关系，此时接口规范了需求功能，接口实现类提供了具体的实现方式。