设计模式原则

设计模式有七大原则，分别是：

1)单一职责原则（Single Responsibility Principle）

2)里氏替换原则（Liskov Substitution Principle, LSP）

3)依赖倒转原则

4)接口隔离原则

5)迪米特法则

6)开闭原则

7)合成复用原则

 

1.单一职责原则（Single Responsibility Principle）

定义：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

问题由来：如类T负责两个不同职责：职责P1，职责P2。当职责P1需求变更而改变T时，可能造成职责P2发生故障

单一职责原则注意事项和细节 

  1. 降低类的复杂度，一个类只负责一项职责
  2. 提高类的可读性，可维护性
  3. 降低变更引起的风险
  4. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则; 只有类中方法数量足够少，可以在方法级别保持单一职责原则

 

2.里氏代换原则（Liskov Substitution Principle, LSP）

定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

      简单来说就是：在程序中，将基类替换为子类，不应产生任何错误和异常。对应到现实世界中，比如有个动物的基类，其中有“进食”的接口，那么所有继承动物积累的老鹰、狮子、鲨鱼，其“进食”的接口都应有效，在调用动物类“进食”接口的地方，改为调用老鹰、狮子、鲨鱼对应的进食”接口，都应正常工作。

里氏替换原则注意事项和细节

  1. 子类应实现所有基类中定义的方法。为了保证系统的扩展性，应在基类中声明各必要接口。如果只在子类中定义方法，将无法无法在以父类定义的对象中使用该方法。
  2. 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。

 

3. 依赖倒转原则（Dependence Inversion Principle）

定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象，其核心思想是：要面向接口编程，不要面向实现编程

      依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

      在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。

依赖倒置原则的作用

  1. 依赖倒置原则可以降低类间的耦合性。
  2. 依赖倒置原则可以提高系统的稳定性。
  3. 依赖倒置原则可以减少并行开发引起的风险。
  4. 依赖倒置原则可以提高代码的可读性和可维护性。

依赖倒置原则注意事项和细节

  1. 每个类尽量提供接口或抽象类，或者两者都具备。
  2. 变量的声明类型尽量是接口或者是抽象类。
  3. 任何类都不应该从具体类派生。
  4. 使用继承时尽量遵循里氏替换原则

 

4.接口隔离原则(Interface Segregation Principle, ISP)

定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构，比如Java语言中的interface。对于这两种不同的含义，ISP的表达方式以及含义都有所不同：

(1) 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。可以把接口理解成角色，一个接口只能代表一个角色，每个角色都有它特定的一个接口，此时，这个原则可以叫做“角色隔离原则”。

(2) 如果把“接口”理解成狭义的特定语言的接口，那么ISP表达的意思是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即为不同的客户端提供宽窄不同的接口。

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

（1）单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。

（2）单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

接口隔离原则的优点

  1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
  2. 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
  3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
  4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
  5. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

接口隔离原则注意事项和细节

  1. 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
  2. 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
  3. 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同，深入了解业务逻辑。
  4. 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

 

5.迪米特法则(Law of Demeter, LoD)

定义：又叫作最少知识原则（Least Knowledge Principle，LKP)，一个软件实体应当尽可能少地与其他实体发生相互作用。

      迪米特法则要求：只与你的直接朋友交谈，不跟“陌生人”说话。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

      在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响。迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。

      在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

迪米特法则的优点

  1. 降低了类之间的耦合度，提高了模块的相对独立性。
  2. 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰

迪米特法则的实现方法

  1. 从依赖者的角度来说，只依赖应该依赖的对象。
  2. 从被依赖者的角度说，只暴露应该暴露的方法。

迪米特法则注意事项和细节

  1. 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
  2. 在类的结构设计上，尽量降低类成员的访问权限。
  3. 在类的设计上，优先考虑将一个类设置成不变类。
  4. 在对其他类的引用上，将引用其他对象的次数降到最低。
  5. 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
  6. 谨慎使用序列化（Serializable）功能。

 

6.开闭原则(Open-Closed Principle, OCP)

定义：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展

问题由来：任何软件都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。因为变化，升级和维护等原因，如果需要对软件原有代码进行修改，可能会给旧代码引入错误，也有可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试，所以当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现使我们需要的。

为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。可以为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

开闭原则注意事项和细节

  1. 一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节。
  2. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
  3. 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

 

7. 合成复用原则

定义：尽量使用合成/聚合的方式，而不是使用继承

 

posted @ 2021-11-08 19:17  亚九  阅读(121)  评论(0)    收藏  举报