Java设计模式基础概述

---

一、什么是设计模式？

软件设计模式，简称设计模式。是一种可以被反复使用、多人知晓、经过分类编目、代码设计经验的总结。简单来说，就是一种经过精心考虑设计的代码设计模板，我们可以使用该设计模板反复套用，提高开发效率、代码的可重用性、代码的可读性、代码的可靠性，解决开发中的一系列问题！

二、为什么要学习设计模式？

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

使用设计模式的好处

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

三、设计模式的基本要素

3.1 设计模式的基本要素

设计模式的基本要素大致可以分为四个主要部分：模式名称、问题、解决方案和效果。

• 模式名称： 每一个模式都有自己的名称，因为我们需要根据模式的问题、特点、解决方案、功能和效果等要素来确定名称，所以名称能太长，一定要方便我们记忆、讨论和设计。另外，模式名称一定要有一击必中的感觉，一个短短的词就可以概括该设计模式的特点以及作用等等。
• 问题： 要确定我们设计的设计模式适用于哪些反复出现的应用环境。也就是哪些应用环境可以用到该设计模式来解决一系列问题。
• 解决方案： 解决方案包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象的 组合）来解决这个问题。
• 效果： 采用该模式对软件系统其他部分的时间、空间分析和影响（优缺点），比如对系统的扩充性、可移植性的影响。影响也包括负面的影响。

3.2 设计模式的其他要素

除了四个主要的基本要素外，还包括很多其他要素，比如：别名、动机、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式。

• 别名： 一个模式可以有超过一个以上的名称。这些名称应该要在这一节注明。简单来说，就像数据库别名一样，可以为此模式取别名来方便记忆、映射其特点、作用等。
• 动机： 该模式应用在哪种场景的情况下，也就是解决问题的动机是什么？就在该环节提出问题与动机的设计。
• 应用： 所谓应用，那就如其所意。映射该模式的应用场景以及如何应用等。
• 结构： 就像设计一款软件一样，我们需要了解并设计它的结构。这里常用类图与互动图阐述此模式的设计结构。
• 模式角色： 提供在此次设计模式中的类与物件的清单，与它们在此设计模式中扮演的角色。
• 合作： 在此设计模式中类与物件的互动与合作。
• 结果： 描述使用该设计模式出现的结果，但是这里结果也是分别好结果与坏结果的，甚至还描述了结果之间的交换问题。
• 实现： 描述实现该模式、该模式的部分方案、实现该模式的可能技术、或者建议实现模式的方法。
• 例程： 示范程式。
• 已知应用： 业务已知的实做范例。
• 相关模式： 相关模式包括其他相关模式，以及与其他类似模式的不同。

四、设计模式分类

设计模式类型可以分为三类分别是创建型、结构型和行为型设计模式。

类型	设计模式
创建型	工厂方法模式、生成器模式、抽象工厂模式、原型模式、单例模式
结构型	适配器（类）模式、桥接模式、容器模式、修饰模式、扩展性模式、外观模式、享元模式、代理模式
行为型	责任链模式、命令模式、解释器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式

五、认识23种设计模式

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

六、设计模式六大原则

注意： 前五个设计原则也属于面向对象五大原则，简称“SOLID”。（面试中问到的SOLID就是它！）

设计原则名称
单一职责原则：SRP（Single responsibility principle）
开放封闭原则/开闭原则：OCP（open close principl）
里氏替换原则：LSP（Liskov Substitution Principle）
接口隔离原则：ISP（Interface Segregation）
依赖倒置原则：DIP（Dependence Inversion Principle）
最少知道原则/迪米特法则：LoD（Law of Demeter）

七、分布式剖析六大设计原则

7.1 单一职责原则

单一职责原则（SRP：Single responsibility principle）表示每个模块、每个类、每个方法都只负责一件事情。

比如：SpringMVC只负责简化MVC开发、Reader类只负责读取文本文件内容、Math.round方法只负责四舍五入

单一职责原则思想演进步骤如下：

大家认识了单一职责原则，想必也知道其作用了。那我们试着写一些代码去证实一下单一职责原则的作用！

首先，我先写一段代码，如下：

public class Test {
    public static void main(String[] args) {
        int num1 = 10;
        int num2 = 20;

        //求和
        int sum = num1 + num2;
        System.out.println(sum);//30

        //求积
        int product = num1 * num2;
        System.out.println(product);//200
    }
}

看到代码的你们是不是觉得这个代码太小儿科了，不就是相加求和和求数的乘积嘛，有什么特别的。但是如果要求我们得出100、200和与乘积怎么办呢？我们延续这段代码的话，就需要在再重新创建两个变量分别存储100和200，再分别求值，对不对。有没有觉得很麻烦，如果要求我们写100个数字分别求和和乘积呢？岂不是难上加难。

由此证明，该例子是一个反例。它破坏了单一职责原则，使代码失去了复用性的特点，很多功能性代码堆积在一起还显得十分冗长，就单单这两点就造成代码的可读性和复用性非常差！

聪明的小伙伴会说，我们封装成方法啊。封装成方法传参不就好了嘛。是的，这才是正解！

public class MathUtils {
    /**
     * 求和
     */
    public int getSum(int num1, int num2) {
        return num1 + num2;
    }

    /**
     * 求积
     */
    public int getProduct(int num1, int num2) {
        return num1 * num2;
    }
}

的确，入门级的两段代码就反映出来了单一职责原则的核心，那我们反过来考虑一下单一职责原则，是不是在我们的程序人生中随处可见呢？小到我们封装的各个方法，大到框架中的SpringMVC等都离不开单一职责原则的约束！

public class Test {
    public static void main(String[] args) {
        //求和
        System.out.println(MathUtils.getSum(100, 200));
        //求积
        System.out.println(MathUtils.getProduct(100, 200));
    }
}

7.2 开放封闭原则/开闭原则

开放封闭原则/开闭原则（OCP：open close principl）表示对功能扩展开放，对修改源码关闭。

比如：软件产品的更新换代、增加新功能。开发人员是非常忌讳去修改项目的源代码的，因为修改源代码来实现产品的更新换代是一件非常危险而且造价极高的操作。所以，项目在架构中需要对功能扩展作以要求。

开闭原则思想演进步骤如下：

为了模拟开闭原则，我们还是使用简单易懂的代码去映射。

首先，我们先创建一个产品实体类——Product

/**
 * 产品类
 */
public class Product {
    private String name;
    private Double price;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Double getPrice() {
        return price;
    }

    public void setPrice(Double price) {
        this.price = price;
    }
}

其次，我们去写一些对产品操作的代码

public class Test {
    public static void main(String[] args) {
        Product iPhone = new Product();
		iPhone.setName=("iPhone11 Plus");
        iPhone.setPrice=(7000.00);
        
        Product huaWei = new Product();
        huaWei.setName("huaWei Mate30 Pro");
        huaWei.setPrice(8000.00);
        
        System.out.println(iPhone.getName() + " 价格：" + iPhone.getPrice());
        System.out.println(huaWei.getName() + " 价格：" + huaWei.getPrice());
    }
}

如果我们的苹果公司和华为公司同时搞活动，这两个产品都打九折呢？于是，我们可以去修改Product实体类的get方法，如下：

public Double getPrice() {
    return price * 0.9;
}

修改后，我们苹果手机和华为手机都同时打了九折。如果这时候，苹果公司先宣布，我们的折扣活动到此为止呢？但是华为公司的折扣活动还在。我们该如何操作呢？所以，在这个时候就需要来纠正一下我们的思想了。首先，我们在此功能扩展（打折）过程中，不能去涉及修改源码（修改实体类）的操作。其次，我们修改源码并不能动态而普适性的解决问题！如果想解决遗留问题，请看如下代码。

public class Discount extends Product{
    @Override
    public Double getPrice() {
        return super.getPrice() * 0.9;
    }
}

public class Test {
    public static void main(String[] args) {
        Product iPhone = new Discount();
        iPhone.setName("iPhone11 Plus");
        iPhone.setPrice(7000.00);
        
        System.out.println(iPhone.getName() + " 价格：" + iPhone.getPrice());
    }
}

为了解决此问题，我们创建了一个打折的类——DIscount。然后重写getPrice方法，并在此方法内做了打折操作，随后使用多态的特性创建iPhone并赋予其参数。这样以来，我们每次打折只需要修改打折类的getPrice方法即可，不需要修改其他的源代码！

开发人员与用户的关系：

在此，我们要知道产品是开发人员做出来的。当产品发布新功能的时候，开发人员会对其产品做扩展。但是用户想要新功能能随便添加吗？他们看得到源码吗？很明显答案肯定为false。所以在软件的开发与使用过程中，开发人员与用户各司其职，各自扮演者自己的角色，对谁都互不干扰！这就是所谓的开闭原则！

7.3 接口隔离原则

接口隔离原则（ISP：Interface Segregation）表示在开发中我们要面向多接口编程，而且一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

接口隔离原则思想演进步骤如下：

其实很好理解，接口隔离原则在最初学习接口的时候，我们就知道了。只是当时不知道接口隔离原则这个名词罢了！那我我写一段代码，演示给大家就明白了！

public interface Animal {
    void fly();

    void swim();
}

public class Bird implements Animal{
    @Override
    public void fly() {
        System.out.println("鸟在天空中飞来飞去");
    }

    @Override
    public void swim() {
        //因为一般的鸟不会游泳，所以我们在这里不做处理
    }
}

public class Fish implements Animal {
    @Override
    public void fly() {
        //因为鱼不会飞，我们在此不做处理
    }

    @Override
    public void swim() {
        System.out.println("鱼在水中游来游去");
    }
}

public class Test {
    public static void main(String[] args) {
        Bird bird = new Bird();
        bird.fly();

        Fish fish = new Fish();
        fish.swim();
    }
}

在此代码中，我们创建了一个Animal接口，里面创建了动物的两种特性，分别为游和飞。大家都知道普通的鱼和鸟分别是游和飞的。这时候我们就需要去实现Animal接口来创建所有方法并挑选其动物的特性再做处理。

这里我们可以这么分析。鸟和鱼就是不同的角色，虽然它们都是属于动物，但是它们各自拥有着不同的特性。显然我们将不同的特性放在一个接口中很不合适，使用此接口变得臃肿，并对角色和接口造成了污染。

所以我们修改代码，让代码变得好起来，如下操作：

public interface Fly {
    void fly();
}

public interface Swim {
    void swim();
}

public class Bird implements Fly{
    @Override
    public void fly() {
        System.out.println("鸟在天空中飞来飞去");
    }
}

public class Fish implements Swim {
    @Override
    public void swim() {
        System.out.println("鱼在水中游来游去");
    }
}

public class Test {
    public static void main(String[] args) {
        Bird bird = new Bird();
        bird.fly();

        Fish fish = new Fish();
        fish.swim();
    }
}

修改操作，也就是去掉了Animal接口，然后创建了飞和游的两个接口，最后让不同的动物去实现不同的特性接口即可。那如果动物有多特性，我们就多实现！

7.4 依赖倒置原则

依赖倒置原则（DIP：Dependence Inversion Principle）表示程序要依赖于抽象接口，不要依赖于具体 实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块 间的耦合。

依赖倒置原则思想演进步骤如下：

依赖倒置，就是角色之间的依赖关系发生的倒置现象，比如下例所示，猫、狗和奥特曼应该都是依赖于人的。但是在下例的代码中，所看出的结果是人依赖于猫、狗、奥特曼。这样如果人需要喂猫，我们就必须在Person类中创建喂猫的方法，那么如果该人是一个动物园饲养员呢？那岂不是得喂成千上百种动物，那么我们就必须在Person类中创建成千上百种的喂养方法吗？答案肯定是false！

class Person {
    public void feedCat(Cat cat) {
        cat.eat();
    }

    public void feedDog(Dog dog) {
        dog.eat();
    }

    public void feedUltraMan(UltraMan ultraMan) {
        ultraMan.eat();
    }
}

class Cat {
    public void eat() {
        System.out.println("猫吃鱼");
    }
}

class Dog {
    public void eat() {
        System.out.println("狗吃肉");
    }
}

class UltraMan {
    public void eat() {
        System.out.println("奥特曼打小怪兽");
    }
}

public class Test {
    public static void main(String[] args) {
        Person person = new Person();
        Cat cat = new Cat();
        Dog dog = new Dog();
        UltraMan ultraMan = new UltraMan();
        person.feedCat(cat);
        person.feedDog(dog);
        person.feedUltraMan(ultraMan);
    }
}

所谓的依赖倒置原则，就是上述所说情景。为了解决此现象的发生，我们需要如下操作！

public class Test {
    public static void main(String[] args) {
        Person person = new Person();
        Cat cat = new Cat();
        Dog dog = new Dog();
        UltraMan ultraMan = new UltraMan();
        person.feedAnimal(cat);
        person.feedAnimal(dog);
        person.feedAnimal(ultraMan);
    }
}

interface Animal {
    void eat();
}

class Person {
    public void feedAnimal(Animal animal) {
        animal.eat();
    }
}

class Cat implements Animal{
    @Override
    public void eat() {
        System.out.println("猫吃鱼");
    }
}

class Dog implements Animal{
    @Override
    public void eat() {
        System.out.println("狗吃肉");
    }
}

class UltraMan implements Animal{
    @Override
    public void eat() {
        System.out.println("奥特曼打小怪兽");
    }
}

解决此问题的所在就是一个核心接口。我们需要在上述代码中，创建一个Animal动物接口，里面写一个eat方法。然后我们需要所有动物去实现此接口并覆盖eat方法。而这时Person类中，我们就需要创建feedAnimal方法就好啦。通过传参的方式就解决了在Person类中创建和修改过多的方法问题了，也就是解决了依赖倒置的问题。这次，你再考虑一下，是不是猫、狗和奥特曼都依赖于人呢？答案已经是显而易见的了，肯定为true！

7.5 里氏替换原则

里氏替换原则（LSP：Liskov Substitution Principle）表示任何父类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。并且子类可以无障碍地替换父类。

里氏替换原则思想演进步骤如下：

首先，要知道我们在使用继承的时候只会考虑一个子类“is a”另一个父类， 我们从来都没有考虑过子类是否可以替换父类。其实在实际的开发中，我们要遵循里氏替换原则的，也就是上述的两方面都必须考虑，这样才能保证业务的完整性，并且不会发生改变。否则，就不能存在继承关系。

也许有伙伴会不明白这里的发生改变是什么意思，后面的例子就会帮助解除你的疑惑！先看代码！

/**
 * 长方形
 */
class Rectangle {
    private int width;
    private int height;

    public int getWidth() {
        return width;
    }

    public void setWidth(int width) {
        this.width = width;
    }

    public int getHeight() {
        return height;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    @Override
    public String toString() {
        return "Rectangle{" +
                "width=" + width +
                ", height=" + height +
                '}';
    }
}

/**
 * 正方形
 */
class Square extends Rectangle {
    //在给定宽的时候同时设置宽和高
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }

    //在给定高的时候同时设置宽和高
    @Override
    public void setHeight(int height) {
        super.setHeight(height);
        super.setWidth(height);
    }
}

public class Test {
    @org.junit.Test
    public void testRectangle() {
        Rectangle rectangle = new Rectangle();
        rectangle.setHeight(100);
        rectangle.setWidth(50);
        System.out.println(rectangle);
    }

    @org.junit.Test
    public void testSquare() {
        Square square = new Square();
        square.setHeight(50);
        System.out.println(square);
    }
}

这里我创建了一个长方形和正方形，根据长方形宽高不一致的特性和正方形宽高（边长）一致的特性，我们可以得出正方形“is a”长方形。简单来说，根据它们的特性，正方形也是一个长方形。那我在代码中，就将正方形继承了长方形创建的宽高。对此传入参数后，并没有什么异常现象出现。

但是，上述中我是不是强调了一个“发生改变”的字眼呢？那么我们就试试呗，如果我们在特定情况下，只改变了长方形的宽，那请问它们两个是继承关系，正方形会怎样呢？会不会发生异常现象呢？

请小伙伴们查看如下改变操作，注意reSize()方法：

/**
 * 长方形
 */
class Rectangle {
    private int width;
    private int height;

    public void reSize() {
        //如果高大于等于宽的话，我们就将宽在原来的基础上增加1
        while (this.height >= this.width) {
            this.setWidth(this.getWidth() + 1);
        }
    }

    public int getWidth() {
        return width;
    }

    public void setWidth(int width) {
        this.width = width;
    }

    public int getHeight() {
        return height;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    @Override
    public String toString() {
        return "Rectangle{" +
                "width=" + width +
                ", height=" + height +
                '}';
    }
}

/**
 * 正方形
 */
class Square extends Rectangle {
    //在给定宽的时候同时设置宽和高
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }

    //在给定高的时候同时设置宽和高
    @Override
    public void setHeight(int height) {
        super.setHeight(height);
        super.setWidth(height);
    }
}

public class Test {
    @org.junit.Test
    public void testRectangle() {
        Rectangle rectangle = new Rectangle();
        rectangle.setHeight(100);
        rectangle.setWidth(50);
        rectangle.reSize();
        System.out.println(rectangle);
    }

    @org.junit.Test
    public void testSquare() {
        Square square = new Square();
        square.setHeight(50);
        rectangle.reSize();
        System.out.println(square);
    }
}

代码中我加了reSize方法在高大于宽的情况下，为宽增加1，并将长方形和正方形同时在内部调用了reSize方法。在我们的测试过程中会发现，长方形的宽增加了1而变为了51。但是正方形呢？正方形却进入了一个死循环的状态。这时候估计就有小伙伴来问为什么了？答案是因为正方型的宽和高是相同的，而reSize方法内判断的条件是>=关系，正方形正好符合=关系，所以也为正方形改变宽+1的操作，但是正方形改变宽必须和高同时修改，这时候的修改却不能做到这一点。所以正方形就陷入到了死循环的状态而不能自拔。

综上所述，我们在实际开发中考虑使用继承的时候一定要遵循里氏替换原则，也就是考虑两个方面。一、是否是“is a”关系；二、子类是否可以替换父类。如果两个条件都符合的话，就可以使用继承。否则，不能使用继承关系！

7.6 最少知道原则/迪米特法则

最少知道原则/迪米特法则（LoD：Law of Demeter）表示一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。

最少知道原则思想演进步骤如下：

最少知道原则，就想它的名字一样，需要最少知道，也就是尽可能少的理解。在开发中保持的尽可能少理解的原则去写代码。为什么呢？看我举一个例子，你就懂了。这大概是在考虑一些情况。比如如下例子：

我们在实际开发中，比如公司新招了一个员工。这时候，新员工需要了解我们的开发流程和进度。

这时候我用通俗易懂的方式来模拟这个场景，就像我们在开发中用电脑的时候，如果想要关闭电脑并关闭电源。我们的操作流程是先保存正在使用的数据、关闭屏幕和关闭电源。正如下所示：

注意：其实这个例子并不恰当，只是我约束了这个流程，来模拟事件而已，大家见谅！

public class Test {
    public static void main(String[] args) {
        CloseComputer closeComputer = new CloseComputer();
        closeComputer.saveData();
        closeComputer.turnOffScreen();
        closeComputer.turnOffHost();
    }
}

class CloseComputer {
    public void saveData() {
        System.out.println("保存数据");
    }

    public void turnOffScreen() {
        System.out.println("关闭屏幕");
    }

    public void turnOffHost() {
        System.out.println("关闭电源");
    }
}

假设上述代码是一个正常的约束流程。我们需要保存数据、关闭屏幕和关闭电源。在这个流程中，我们的哪一个步骤都不能发生位置以及其他错误。这时候，我们招来的新员工并不熟悉该操作，这就有可能会造成数据的丢失，为公司造成或大或小的损失。这时候，就算是我们需要知道的很多，才能正常、正确的跑完这个流程。所以，这时候我们要简化这个流程，让新员工知道很少的原则就可以实现。同时，在简化流程的过程中，为数据增加了一种保障，避免了误操作的风险。

至于如何简化流程，就看我编写的如下代码吧！

public class Test {
    public static void main(String[] args) {
        CloseComputer closeComputer = new CloseComputer();
        closeComputer.closeAll();
    }
}

class CloseComputer {
    public void closeAll() {
        saveData();
        turnOffScreen();
        turnOffHost();
    }

    public void saveData() {
        System.out.println("保存数据");
    }

    public void turnOffScreen() {
        System.out.println("关闭屏幕");
    }

    public void turnOffHost() {
        System.out.println("关闭电源");
    }
}

该操作，我将流程中的具体操作以正确的方式封装在一个方法中，这时候我们的新员工不用知道过多的原则（简化流程后），就可以正确的跑完流程。既为新员工降低了压力，又避免了数据丢失的风险。想想岂不是两全其美！

---