设计模式

学习资料 747 2021年3月5日 0 云创动力

设计模式

1、什么是设计模式

设计模式（Design pattern）是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。它代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。这个术语是由埃里希·伽玛（Erich Gamma）等四人（四位作者合称 GOF（四人组，全拼 Gang of Four））在 1994 年所出版的Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书中首次提到了软件开发中设计模式的概念。

2、设计模式的重要性

高楼大厦 VS 简易房

面向对象的特点是 可维护、可复用、可扩展、灵活性好，它最强大的地方在于：随着业务变得越来越复杂，面向对象依然能够使得程序结构良好，而面向过程却会导致程序越来越臃肿。让面向对象保持结构良好的秘诀就是设计模式，面向对象结合设计模式，才能真正体会到程序变得可维护、可复用、可扩展、灵活性好。
目前程序员门槛越来越高，一线 IT 公司(大厂)，都会问你在实际项目中使用过什么设计模式，怎样使用的，解决了什么问题。
流行框架中很多地方都使用了设计模式

软件：面向对象（oop）语言 --> 功能模块 --> 框架 --> 架构
如果要成为合格的软件工程师，那么花时间来研究下设计模式是非常必要的

4、软件设计模式的基本要素

软件设计模式使人们可以更加简单方便地复用成功的设计和体系结构，它通常包含以下几个基本要素：模式名称、别名、动机、问题、解决方案、效果、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式等，其中最关键的元素包括以下 4 个主要部分:

4.1、模式名称

每一个模式都有自己的名字，通常用一两个词来描述，可以根据模式的问题、特点、解决方案、功能和效果来命名。

4.2、问题

问题（Problem）描述了该模式的应用环境，即何时使用该模式。它解释了设计问题和问题存在的前因后果，以及必须满足的一系列先决条件。

4.3、解决方案

模式问题的解决方案（Solution）包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象的组合）来解决这个问题。

4.4、效果

描述了模式的应用效果以及使用该模式应该权衡的问题，即模式的优缺点。主要是对时间和空间的衡量，以及该模式对系统的灵活性、扩充性、可移植性的影响，也考虑其实现问题。

6、设计模式七大原则

6.1、设计模式的目的

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点:

可以提高程序员的思维能力、编程能力和设计能力。
使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强
高内聚，低耦合

6.2、设计模式七大原则

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即：设计模式为什么这样设计的依据)

6.2.3 开闭原则（Open Closed Principle，OCP）

开放-关闭原则表示软件实体 (类、模块、函数等等) 应该是可以被扩展的，但是不可被修改。(Open for extension, close for modification) ，是编程中最基础、最重要的设计原则

如果一个软件能够满足 OCP 原则，那么它将有两项优点：

能够扩展已存在的系统，能够提供新的功能满足新的需求，因此该软件有着很强的适应性和灵活性。
已存在的模块，特别是那些重要的抽象模块，不需要被修改，那么该软件就有很强的稳定性和持久性。

举例：

某系统的后台需要监测业务数据展示图表，如柱状图、折线图。

class BarChart {
    public void draw(){
        System.out.println("画折线图...");
    }
}

class LineChart {
    public void draw(){
        System.out.println("画柱状图...");
    }
}

public class App {

    public void drawChart(String type){
        if (type.equalsIgnoreCase("line")){
            new LineChart().draw();
        }else if (type.equalsIgnoreCase("bar")){
            new BarChart().draw();
        }
    }
}

这样做在初期是能满足业务需要的，但是当后面需要新增一个饼状图的时候，既要添加一个饼状图的类，原来的客户端App类的drawChart方法也要新增一个if分支，这样做就是修改了原有客户端类库的方法，是十分不合理的。

因此，需要引入一个抽象Chart类AbstractChart，App类在画图的时候总是把相关的操作委托到具体的AbstractChart的派生类实例，这样的话App类的代码就不用修改：

abstract class AbstractChart {

    abstract void draw();
}

class BarChart extends AbstractChart{

    @Override
    public void draw() {
        System.out.println("画柱状图...");
    }
}

class LineChart extends AbstractChart {

    @Override
    public void draw() {
        System.out.println("画折线图...");
    }
}

class PieChart extends AbstractChart {

    @Override
    public void draw() {
        System.out.println("画饼状图...");
    }
}

public class App {

    public void drawChart(AbstractChart chart){
        chart.draw();
    }
}

此时，如果新加一种图，只需要新增一个AbstractChart的子类即可。客户端类App不需要改变原来的逻辑。修改后的设计符合开闭原则，因为整个系统在扩展时原有的代码没有做任何修改。

6.2.1 单一职责原则（Single Responsibility Principle, SRP）

基本介绍

单一职责原则表示一个模块的组成元素之间的功能相关性。从软件变化的角度来看，对类来说，一个类应该只负责一项职责。（应该仅有一个引起它变化的原因）

假设某个类 P 负责两个不同的职责，职责 P1 和职责 P2，那么当职责 P1 需求发生改变而需要修改类 P，有可能会导致原来运行正常的职责 P2 功能发生故障。所以需要将类 P 的粒度分解为 P1，P2

适用于：模块、类、接口、方法

举例

以交通工具案例为例：

/**
 * 交通工具类
 */
class Vehicle {

    /**
     * @param vehicle 交通工具名称
     */
    public void run(String vehicle) {
        System.out.println(vehicle + "在公路上行驶中...");
    }
}

public class SingleResponsibilityDemo {

    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("摩托车");
        vehicle.run("汽车");
        vehicle.run("飞机");
    }

}

运行结果:

分析：

run方法违反了单一职责原则，应该根据交通工具运行方法不同，分解成不同类

class RoadVehicle{
    public void run(String vehicle){
        System.out.println(vehicle + "在公路上行驶...");
    }
}

class AirVehicle{
    public void run(String vehicle){
        System.out.println(vehicle + "在天空中行驶...");
    }
}

class WaterVehicle{
    public void run(String vehicle){
        System.out.println(vehicle + "在水中行驶...");
    }
}

public class SingleResponsibilityDemo2 {

    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("摩托车");
        roadVehicle.run("汽车");

        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("飞机");

        WaterVehicle waterVehicle = new WaterVehicle();
        waterVehicle.run("轮船");
    }
}

运行结果：

分析：

虽然遵守了单一职责原则，但是对比之前的代码改动很大。所以我们再进行一次改进，我们直接修改 Vehicle 类。

class Vehicle {
    
    public void run(String vehicle) {
        System.out.println(vehicle + "在公路上行驶...");
    }
    public void runAir(String vehicle){
        System.out.println(vehicle + "在天空中行驶...");
    }
    public void runWater(String vehicle){
        System.out.println(vehicle + "在水中行驶...");
    }
}

实际项目代码编写的时候，由于历史原因和人为的不规范，导致项目没有分层，可能出现如下这种情况：

public class UserDao{

    public User findUserByName(String name){
       Connection connection = getConnection();
        PreparedStatement preparedStatement = connection.prepareStatement("SELECT * FROM t_user WHERE name = ?");
        preparedStatement.setObject(1, name);
        User user = //处理结果
        return user;
    }
}

在一个Dao中，比如:UserDao，本来应该只进行对User表的相关操作及结果的封装。但是出现了数据库连接的管理等操作，那么当出现更换数据库等需求时，这个方法将会大改。因此，我们需要拆分出新的DBUtils类用于专门管理数据库资源，做到每个类的职责分明。

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

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

6.2.2 接口隔离原则（Interface Segregation Principle，ISP）

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

接口隔离原则，其 "隔离" 并不是准确的翻译，真正的意图是 “分离” 接口(的功能), 也就是接口尽量细化，同时接口中的方法尽量少。

举例

图中表示，类 A 依赖于接口 I 中的方法 1，2，3 ，类 B 是对类 A 的具体实现。类 C 依赖接口 I 中的方法 1，4，5，类 D 是对类 C 的具体实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。

代码表示：

// 接口 I
interface I {
    void method1();
    void method2();
    void method3();
    void method4();
    void method5();  
}
// 类 A 依赖于 接口 I 中的方法 1，2，3 
class A{
    public void depend1(I i){
        i.method1();
    }
    public void depend2(I i){
        i.method2();
    }
    public void depend3(I i){
        i.method3();
    }
}
// 类 C 依赖接口 I 中的方法 1，4，5
class C{  
    public void depend1(I i){  
        i.method1();  
    }  
    public void depend2(I i){  
        i.method4();  
    }  
    public void depend3(I i){  
        i.method5();  
    }  
}
// 类 B 只需要实现方法 1，2, 3，而其它方法它并不需要，但是也需要实现
class B implements I{ 
    @Override
    public void method1() {
        System.out.println("类 B 实现接口 I 的方法 1");
    }
    @Override
    public void method2() {
        System.out.println("类 B 实现接口 I 的方法 2");
    }
    @Override
    public void method3() {
        System.out.println("类 B 实现接口 I 的方法 3");
    }
    @Override
    public void method4() {}
    @Override
    public void method5() {}
}

// 类 D 只需要实现方法 1，4，5，而其它方法它并不需要，但是也需要实现
class D implements I{
    
    @Override
    public void method1() {
        System.out.println("类 D 实现接口 I 的方法 1");
    }
    @Override
    public void method2() {}
    @Override
    public void method3() {}
    @Override
    public void method4() {
        System.out.println("类 D 实现接口 I 的方法 4");
    }
    @Override
    public void method5() {
        System.out.println("类 D 实现接口 I 的方法 5");
    }
}
// 客户端
public class Client{
    public static void main(String[] args){
        A a = new A();
        a.depend1(new B());
        a.depend2(new B());
        a.depend3(new B());

        C c = new C();
        c.depend1(new D());
        c.depend2(new D());
        c.depend3(new D());
    }
}

分析:

可以看出，如果接口定义的过于臃肿，只要接口中出现的方法，不管依赖于它的类是否需要该方法，实现类都必须去实现这些方法，这就不符合接口隔离原则，如果想符合接口隔离原则，就必须对接口 I 如下图进行拆分：

代码可修改为如下：

interface I1 {
    public void method1();
}

interface I2 {
    public void method2();
    public void method3();
}

interface I3 {
    public void method4();
    public void method5();
}

class A{  
    public void depend1(I1 i){  
        i.method1();  
    }  
    public void depend2(I2 i){  
        i.method2();  
    }  
    public void depend3(I2 i){  
        i.method3();  
    }  
}  
  
class B implements I1, I2{  
    public void method1() {  
        System.out.println("类 B 实现接口 I1 的方法 1");  
    }  
    public void method2() {  
        System.out.println("类 B 实现接口 I2 的方法 2");  
    }  
    public void method3() {  
        System.out.println("类 B 实现接口 I2 的方法 3");  
    }  
}  

class C{  
    public void depend1(I1 i){  
        i.method1();  
    }  
    public void depend2(I3 i){  
        i.method4();  
    }  
    public void depend3(I3 i){  
        i.method5();  
    }  
}  
  
class D implements I1, I3{  
    public void method1() {  
        System.out.println("类 D 实现接口 I1 的方法 1");  
    }  
    public void method4() {  
        System.out.println("类 D 实现接口 I3 的方法 4");  
    }  
    public void method5() {  
        System.out.println("类 D 实现接口 I3 的方法 5");  
    }  
}

总结：

依赖几个专用的接口要比依赖一个综合的接口更灵活
运用接口隔离原则，一定要适度，接口设计的过大或过小都不好

6.2.4 依赖倒转(倒置)原则（Dependency Inversion Principle，DIP）

依赖倒转原则(Dependence Inversion Principle)是指：

高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
依赖倒转(倒置)的中心思想是面向接口编程
依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类
使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

举例:

class BMW{
  
    public String getName(){
        return "宝马";
    }
}

public class Driver {

    public void drive(BMW car){
        System.out.println("开着一辆" + car.getName());
    }
}

但是现在我们的车换成一辆大奔的话，我们的Driver类就要新增相应的方法。因此我们此时引入一个抽象的接口Car，这样Driver类与Car发生依赖，而BMW和Benz都实现Car。这样就符合依赖倒置原则

interface Car{
    String getName();
}

class BMW implements Car{
    @Override
    public String getName(){
        return "宝马";
    }
}

class Benz implements Car{

    @Override
    public String getName() {
        return "大奔";
    }
}

public class Driver {

    public void drive(Car car){
        System.out.println("开着一辆" + car.getName());
    }
}

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

低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
变量的声明类型尽量是抽象类或接口, 这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化
继承时遵循里氏替换原则

6.2.5 里氏替换原则（Liskov Substitution Principle，LSP）

OOP 中的继承性的思考和说明

继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。

继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障

此时就会产生一个问题：在编程中，如何正确的使用继承? 答案就是里氏替换原则

里氏替换原则介绍

里氏替换原则(Liskov Substitution Principle)在 1988 年，由麻省理工学院的以为姓里的女士提出的。

如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。

里氏替换原则通俗的来讲就是：系统中所有引用父类的地方都必须能使用其子类对象，子类对象能够替换父类对象，而程序逻辑不变。子类可以扩展父类的功能，但不能改变父类原有的功能。

举例

我们需要完成一个两数相减的功能：

class A{  
    public int func1(int a, int b){  
        return a - b;  
    }  
}

后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要完成两个功能：

两数相减
两数相加，然后再加100

由于类A已经实现了第一个功能，所以类B继承类A后，只需要再完成第二个功能就可以了，代码如下:

class B extends A{
    @Override
    public int func1(int a, int b){
        return a + b;
    }
    public int func2(int a, int b){
        return func1(a, b) + 100;
    }
}
public class LiskovDemo {

    public static void main(String[] args) {
        A a = new A();
        System.out.println("11-3=" + a.func1(11, 3));
        System.out.println("1-8=" + a.func1(1, 8));

        System.out.println("-----------------------");

        B b = new B();
        System.out.println("11+3+100=" + b.func2(11, 3));
        System.out.println("11-3=" + b.func1(11, 3));//这里本意是求出 11-3
        System.out.println("1-8=" + b.func1(1, 8));// 这里本意是求出 1-8
    }
}

分析

我们发现原来原本运行正常的相减功能发生了错误，原因就是类 B 在给方法起名时无意中重写了父类的方法，造成了所有运行相减功能的代码全部调用了类 B 重写后的方法，造成原来运行正常的功能出现了错误。在实际编程中，我们常常会通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是这样往往也增加了重写父类方法所带来的风险。

解决方案

通用的做法是：原有的继承关系去掉，采用依赖，聚合，组合等关系代替。例如:

class B{

    private A a = new A();

    // 即使无意识的创建了同名方法
    public int func1(int a, int b) {
        return a + b;
    }

    public int func2(int a, int b) {
        return func1(a, b) + 100;
    }

    public int func3(int a, int b){
        //仍然可以使用 A 的方法
        return this.a.func1(a, b);
    }
}

里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。

里氏替换原则的重点在不影响原功能，而不是不覆盖原方法。

6.2.6 迪米特法则（Law of Demeter，LOD）

迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息
类与类关系越密切，耦合度越大
迪米特法则还有个更简单的定义：只与直接的朋友通信
直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部

举例:

举个例子，家人探望犯人

家人：家人只与犯人是亲人，但是不认识他的狱友
犯人：犯人与家人是亲人，犯人与狱友是朋友
狱友: 犯人与狱友是朋友，但是不认识他的家人

// 家人
class Family {
    public void visitPrisoner(Prisoners prisoners) {
        Inmates inmates = prisoners.helpEachOther();
        inmates.weAreFriend();
    }
}
// 犯人
class Prisoners {
    private Inmates inmates = new Inmates();
    public Inmates helpEachOther() {
        System.out.println("家人说：你和狱友之间应该互相帮助...");
        return inmates;
    }
}
// 狱友
class Inmates {
    public void weAreFriend() {
        System.out.println("狱友说：我们是狱友...");
    }
}
// 场景类：发生在监狱里
public class Prison {
    public static void main(String args[])
    {
        Family family = new Family();
        family.visitPrisoner(new Prisoners());
    }
}

运行结果:

程序正常运行，但是有一个问题。Family类中,Inmates类作为局部变量出现在了方法中并不是它的直接朋友，也就是陌生类所以违反了迪米特法则。也就是说家人和狱友显然是不认识的，且监狱只允许家人探望犯人，而不是随便谁都可以见面的，这里家人和狱友有了沟通显然是违背了迪米特法则。所以上述的代码可以改为：

// 家人
class Family {
    public void visitPrisoner(Prisoners prisoners) {
        prisoners.helpEachOther();
    }
}
// 犯人
class Prisoners {
    private Inmates inmates = new Inmates();
    public Inmates helpEachOther() {
        System.out.println("家人说：你和狱友之间应该互相帮助...");
        inmates.weAreFriend();
        return inmates;
    }
}

这样家人和狱友就分开了，但是也表达了家人希望狱友能跟犯人互相帮助的意愿。也就是两个类通过第三个类实现信息传递, 而家人和狱友却没有直接通信。

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

迪米特法则的核心是降低类之间的耦合

但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系，并不是要求完全没有依赖关系

6.2.7 合成复用原则

组合/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分; 新的对象通过向这些对象的委派达到复用已有功能的目的。

在面向对象的设计中，如果直接继承基类，会破坏封装，因为继承将基类的实现细节暴露给子类；如果基类的实现发生了改变，则子类的实现也不得不改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。于是就提出了组合/聚合复用原则，也就是在实际开发设计中，尽量使用组合/聚合，不要使用类继承

举例：

在某家公司里的员工分为经理，工作者和销售者。如果画成 UML 图可以表示为：

使用继承来实现角色，则只能使每一个“员工”具有Is-A角色，而且继承是静态的，这会使得一个“员工”在成为“经理”身份后，就永远为“经理”，不能成为“工作者”和“销售者”，而这显然是不合理的。这一错误的设计源自于把“角色”的等级结构和“员工”的等级结构混淆起来，把“Has-A”角色误解为“Is -A”角色。如果要遵守组合聚合复用原则，可以将其改为：

把角色Role聚合到员工Employee中,那么这个角色Role就可以是经理，工作者或者销售者。

5、设计模式的分类和功能

5.1、根据目的来分

根据模式是用来完成什么工作来划分，这种方式可分为:

创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。
行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。

5.2、根据作用范围来分

根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式

类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。工厂方法、（类）适配器、模板方法、解释器属于该模式。
对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。

5.3、23种设计模式的功能

单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例。
原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

设计模式

设计模式

1、什么是设计模式

2、设计模式的重要性

4、软件设计模式的基本要素

4.1、模式名称

4.2、问题

4.3、解决方案

4.4、效果

6、设计模式七大原则

6.1、设计模式的目的

6.2、设计模式七大原则

6.2.3 开闭原则（Open Closed Principle，OCP）

6.2.1 单一职责原则（Single Responsibility Principle, SRP）

6.2.2 接口隔离原则（Interface Segregation Principle，ISP）

6.2.4 依赖倒转(倒置)原则（Dependency Inversion Principle，DIP）

6.2.5 里氏替换原则（Liskov Substitution Principle，LSP）

6.2.6 迪米特法则（Law of Demeter，LOD）

6.2.7 合成复用原则

5、设计模式的分类和功能

5.1、根据目的来分

5.2、根据作用范围来分

5.3、23种设计模式的功能

学员日志

近期文章

分类目录

近期评论

作者

热门

标签

2023年3月
一	二	三	四	五	六	日
« 9月
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

设计模式

1、什么是设计模式

2、设计模式的重要性

4、软件设计模式的基本要素

4.1、 模式名称

4.2、 问题

4.3、解决方案

4.4、效果

6、设计模式七大原则

6.1、设计模式的目的

6.2、设计模式七大原则

6.2.3 开闭原则（Open Closed Principle，OCP）

6.2.1 单一职责原则（Single Responsibility Principle, SRP）

6.2.2 接口隔离原则（Interface Segregation Principle，ISP）

6.2.4 依赖倒转(倒置)原则（Dependency Inversion Principle，DIP）

6.2.5 里氏替换原则（Liskov Substitution Principle，LSP）

6.2.6 迪米特法则（Law of Demeter，LOD）

6.2.7 合成复用原则

5、设计模式的分类和功能

5.1、根据目的来分

5.2、 根据作用范围来分

5.3、23种设计模式的功能

学员日志

近期文章

标签

分类目录

近期评论

作者

热门

标签

相关推荐

4.1、模式名称

4.2、问题

5.2、根据作用范围来分