设计模式前言

zz_zry

已于 2023-02-19 16:52:33 修改

阅读量103

点赞数

分类专栏：设计模式文章标签： java

于 2020-04-04 14:57:24 首次发布

本文链接：https://blog.csdn.net/zry19950714/article/details/105309200

版权

设计模式专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、什么是设计模式

设计模式是一套被反复使用的、多数人知晓的、经过分门编类的、代码设计总结，其目的就是为了使代码能重复利用，容易被他人理解，且能保证代码可靠性。设计模式使代码编制变得工程化，设计模式相当于房屋设计的基本框架。项目中合理的运用设计模式可以完美的解决很多问题，每一种设计模式都有相应的原理与之对应，每种模式都在描述一个在我周围不断发生的问题，以及该问题的核心解决方法，这也是设计模式能被广泛应用的原因。

二、设计模式起源

由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则。

对接口编程而不是对实现编程
优先使用对象组合而不是继承

三、设计模式的6大原则

1. 开闭原则(Open Close Principle)

开闭原则的意思是：对扩展开发，对修改关闭。在对程序进行拓展时，不能去修改原有的代码，而是要实现一个热插拔的效果。简而言之，是为了使程序扩展性好，易于维护与升级。想要达到这样的效果，我们需要使用接口与抽象类。类必须做到高内聚，低耦合。

2. 里氏替换原则(Liskov Substitution Principle)

所有引用基类的地方都必须能透明的使用其子类的对象，即只要父类能出现的地方子类就能出现，而且替换为子类也不会产生任何的错误或异常，因此程序中尽量使用基类类型定义变量，在运行时候再确定子类的类型，用子类对象代替父类引用。但有子类出现的地方，父类未必能适应。

在使用LSP时，需注意以下几点：

(1) 子类必须完全实现父类的方法，在程序中使用父类进行声明对象。如果一个方法只存在子类中，则父类对象无法使用该方法。如果子类不能完全的实现父类的方法，则要考虑断开继承关系，采用依赖集组合的等关系代替继承。

(2) 在用LSP时，尽量把父类设计成接口或抽象类，让子类继承或实现接口，并实现声明在父类中的方法，运行时代替父类实例，要进行系统扩展时，不需要修改以前子类的代码，只要再增加一个新的子类来实现即可。

(3) 子类在覆盖或者实现父类的方法时，输入参数可以被放大。换句话说如果你想让子类dd的方法运行，则必须重写父类的方法，也可以重载这个方法，但是前提是子类的参数范围要大于父类的参数范围。

(4) 重写或实现父类的方法时输出结果类型要小于等于父类的输出结果

一个简单的例子，VIP与普通用于都需要发送邮箱，其步骤是一样的，因此可抽象出几个公共方法作为父类。

重构后

3. 依赖倒置原则(DIP)

(1) 模块之间的依赖是通过抽象发生的，实现类直接不可以直接依赖，实现类的依赖关系是通过接口或者抽象的类产生的。

(2) 接口或者抽象类不依赖实现类

(3) 实现类要依赖接口或抽象类

精简的定义就是面向接口编程，依赖倒转原则要求我们在程序代码中传递参数或者关联关系中，尽量的去引用高层次的抽象类，即用接口和抽象类进行变量类型的声明、参数类型的声明（这点实际应用中较为麻烦）、方法返回类型的声明以及数据类型的转换等，而不是用具体的类来做这些事情。在引入抽象后，系统拥有很好的灵活性，在程序中尽量使用抽象层进行编程，当系统行为发生改变时，只需要对抽象层进行扩展即可，不需要修改原有的代码。

在实现依赖倒置原则时，我们需要对抽象层编程，而将具体的对象通过依赖注入的方式注入到其他对象中去。依赖注入指的是一个对象与另一个对象发生依赖的时候，通过抽象来注入依赖对象。依赖注入的三种方式，构造函数注入，setget注入和接口注入，常用前两种。

4. 接口隔离原则(ISP)

接口隔离原则指的是使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。接口尽量的细化，同时接口的方法尽量的少。一般而言，接口中仅包含为某一类用户定制的方法即可。

5. 迪米特原则(LoD)

一个软件实体应当尽可能少的与其他实体发生相互作用。迪米特原则可以降低系统的耦合度，使类与类之间保持松耦合的关系。

6. 单一原则(SPR)

一个类中应当有且仅有一个原因导致该类的变更，换句话说就是一个类只应该负责一项职责。SPR的优点是消除耦合，减小因需求的变化引起的代码僵化的问题。SPR强调的就是根据职责来衡量接口或者类，但是往往我们对于职责定义不明确，因此我们要因项目而异。一个合理的类中尽量做到仅由一个原因引起它的变化，但是对于接口一定要做到单一原则，在需求发生变化的时候应该使用SPR等原则来重构代码。