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

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想要实现的功能,而只是改变了功能的实现方式。

  原则描述的是两种关系,

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

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

原文地址:https://www.cnblogs.com/rain144576/p/12330113.html