设计模式以及其最佳的实践

最新推荐文章于 2024-07-06 19:10:28 发布
最新推荐文章于 2024-07-06 19:10:28 发布
阅读量797 收藏 14
点赞数 13
文章标签： 设计模式 java 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ShockChen7/article/details/139240479
版权

工厂模式

工厂模式通常包括以下几种变体：

  1. 简单工厂模式（Simple Factory Pattern）： 简单工厂模式通过一个工厂类来负责对象的创建，客户端通过调用工厂类的静态方法或者实例方法来获取对象。简单工厂模式将对象的创建过程封装在一个工厂类中，对客户端隐藏了对象的创建细节。

  2. 工厂方法模式（Factory Method Pattern）： 工厂方法模式通过定义一个抽象的工厂接口和多个具体的工厂类来创建对象。每个具体的工厂类负责创建特定类型的对象，客户端可以根据需要选择不同的工厂类来创建对象。工厂方法模式允许客户端在不修改现有代码的情况下添加新的产品类。

  3. 抽象工厂模式（Abstract Factory Pattern）： 抽象工厂模式通过定义一个抽象工厂接口和多个具体的工厂类来创建一系列相关或依赖的对象。每个具体的工厂类负责创建一组相关的产品对象，客户端可以通过选择不同的具体工厂类来获取不同系列的产品对象。抽象工厂模式强调了产品族的概念，适用于需要创建一组相关对象的场景。

1. 简单工厂模式

简单工厂模式通过一个工厂类来负责对象的创建。把创建车的操作细节都放到了工厂里，而客户直接使用工厂的创建方法，传入想要的车型号就行了，而不必去知道创建的细节，其实就是对创建对象的过程进行解耦，屏蔽细节。

下面是一个示例，工厂类创建不同类型的产品（如Car）:

// 产品接口
interface Car {
    void drive();
}

// 具体产品类
class BMW implements Car {
    public void drive() {
        System.out.println("驾驶BMW");
    }
}

class SUV implements Car {
    public void drive() {
        System.out.println("驾驶SUV");
    }
}

// 简单工厂类
class CarFactory {
    public static Car createCar(String type) {
        switch (type) {
            case "BMW":
                return new BMW();
            case "SUV":
                return new SUV();
            default:
                throw new IllegalArgumentException("未知的车型");
        }
    }
}

// 客户端代码
public class SimpleFactoryDemo {
    public static void main(String[] args) {
        Car bmw = CarFactory.createCar("BMW");
        bmw.drive();
        
        Car suv = CarFactory.createCar("SUV");
        suv.drive();
    }
}

2. 工厂方法模式

工厂方法模式通过定义一个抽象的工厂接口和多个具体的工厂类来创建对象。每个具体的工厂类负责创建特定类型的对象。

每增加新产品，只需增加该产品以及对应的具体实现工厂类，由具体工厂类决定要实例化的产品是哪个，将对象的创建与实例化延迟到子类，这样工厂的设计就符合“开闭原则”了，扩展时不必去修改原来的代码。

// 产品接口
interface Car {
    void drive();
}

// 具体产品类
class BMW implements Car {
    public void drive() {
        System.out.println("驾驶BMW ");
    }
}

class SUV implements Car {
    public void drive() {
        System.out.println("驾驶SUV");
    }
}

// 抽象工厂接口,工厂方法模式将工厂抽象化，并定义一个创建对象的接口。
interface CarFactory {
    Car createCar();
}

// 具体工厂类
class BMWFactory implements CarFactory {
    public Car createCar() {
        return new BMW();
    }
}

class SUVFactory implements CarFactory {
    public Car createCar() {
        return new SUV();
    }
}

// 客户端代码
public class FactoryMethodDemo {
    public static void main(String[] args) {
        BMWFactory bmwFactory = new BMWFactory();
        Car bmw = bmwFactory.createCar();
        bmw.drive();
        
        CarFactory suvFactory = new SUVFactory();
        Car suv = suvFactory.createCar();
        suv.drive();
    }
}

3. 抽象工厂模式

通过抽象工厂模式，我们可以实现以下的效果：比如户外的时候生产SUV和山地自行车，城市中的时候生产BMW和公路自行车。

每个具体的工厂类负责创建一组相关的产品对象，客户端可以通过选择不同的具体工厂类来获取不同系列的产品对象。抽象工厂模式强调了产品族的概念，适用于需要创建一组相关对象的场景。

// 抽象产品A
interface Car {
    void drive();
}

// 具体产品A1
class BMW implements Car {
    public void drive() {
        System.out.println("驾驶BMW ");
    }
}

// 具体产品A2
class SUV implements Car {
    public void drive() {
        System.out.println("Driving an SUV");
    }
}

// 抽象产品B自行车
interface Bike {
    void ride();
}

// 具体产品B1
class RoadBike implements Bike {
    public void ride() {
        System.out.println("骑公路车");
    }
}

// 具体产品B2
class MountainBike implements Bike {
    public void ride() {
        System.out.println("骑山地车");
    }
}

// 抽象工厂接口
interface VehicleFactory {
    Car createCar();
    Bike createBike();
}

// 具体工厂类1 城市交通工具工厂
class UrbanVehicleFactory implements VehicleFactory {
    public Car createCar() {
        return new BMW();
    }
    public Bike createBike() {
        return new RoadBike();
    }
}

// 具体工厂类2 野外交通工具工厂
class OutdoorVehicleFactory implements VehicleFactory {
    public Car createCar() {
        return new SUV();
    }
    public Bike createBike() {
        return new MountainBike();
    }
}

// 客户端代码
public class AbstractFactoryDemo {
    public static void main(String[] args) {
        VehicleFactory urbanFactory = new UrbanVehicleFactory();
        Car bmw = urbanFactory.createCar();
        Bike roadBike = urbanFactory.createBike();
        bmw.drive();
        roadBike.ride();
        
        VehicleFactory outdoorFactory = new OutdoorVehicleFactory();
        Car suv = outdoorFactory.createCar();
        Bike mountainBike = outdoorFactory.createBike();
        suv.drive();
        mountainBike.ride();
    }
}

策略模式

策略模式是一种行为设计模式，用于定义一组算法并将其封装起来，使它们可以相互替换。策略模式使得算法的变化独立于使用算法的客户端。

在策略模式中，通常有三个角色：

  • 上下文（Context）： 上下文是客户端代码所调用的对象，持有一个策略类的引用，最终给客户端调用。

  • 策略（Strategy）： 策略是一个接口或者抽象类，定义了一个算法族的公共接口。具体的策略类实现了这个接口，每个策略类封装了一种具体的算法。

  • 具体策略（Concrete Strategy）： 具体策略是策略的具体实现类，实现了策略接口定义的算法。具体策略类之间可以相互替换，客户端可以在运行时选择不同的具体策略来实现不同的算法。

在这里插入图片描述
算法的独立性： 策略模式将算法的实现从上下文中分离出来，使得算法可以独立于客户端而变化。这样一来，客户端可以根据需要选择不同的策略，而不需要修改原有的代码。

易于扩展： 新的策略可以很容易地被添加到系统中，无需修改现有的代码，只需实现相应的策略接口即可。

减少条件判断： 策略模式可以避免大量的条件判断语句，使得代码更加清晰和易于理解。

封装性良好： 策略模式将算法封装在独立的策略类中，使得每个策略类都可以独立地进行单元测试和维护。

最佳实践：

下面是一个实例，根据音乐文件的后缀名不同，选择不同的策略来下载音乐文件中的封面图片。

封面下载接口如下：

	/**
     * 封面下载
     */
    @ResponseBody
    @GetMapping("/cover/{filename}")
    public void cover(@PathVariable String filename, HttpServletResponse response){
        // 获取文件扩展名
        String fileExtension = filename.substring(filename.lastIndexOf(".") + 1);
        // 获取封面下载策略
        CoverStrategy coverStrategy = CoverStrategyFactory.getCoverStrategy(fileExtension);
        // 调用策略
        coverStrategy.download(UPLOAD_DIR + filename,response);
    }

CoverStrategy 策略接口：

/**
 * 策略接口，定义抽象方法dowload。
 * 实现该接口的类需要实现下载文件的方法。
 */
public interface CoverStrategy {

    void download(String filepath, HttpServletResponse response) ;
}

CoverStrategyFactory 封面策略工厂类：

/**
 * 封面策略工厂类,用于根据文件扩展名返回相应的策略实现。
 */
public class CoverStrategyFactory {
	// 存储文件扩展名与对应的策略实现的映射关系
    private static Map<String, CoverStrategy> coverStrategyMap = new ConcurrentHashMap<>();
	//根据后缀名返回对应的策略类
    public static CoverStrategy getCoverStrategy(String fileExtension) {
    	//如果没有对应的策略 返回默认策略
        if (!coverStrategyMap.containsKey(fileExtension)) {
            return new BaseCoverStrategy();
        }
        //从map中选择对应策略
        return coverStrategyMap.get(fileExtension);
    }

	/**
     * 注册新的策略实现到工厂中。
     * 通过文件扩展名作为键，将对应的策略实现存储到map中。
     *
     * @param fileExtension 文件扩展名，如 "jpg", "png", "txt" 等。
     * @param coverStrategy 对应文件扩展名的策略实现。
     */
    public static void register(String fileExtension,CoverStrategy coverStrategy) {
        coverStrategyMap.put(fileExtension, coverStrategy);
    }
}

BaseCoverStrategy 基本封面策略类：实现了 CoverStrategy 接口并实现了下载方法，该类还实现了 InitializingBean 接口，在 Spring 初始化完成后把自身注册为 mp3 和 flac 文件扩展名对应的策略。


/**
 * 基本的音频封面图片获取策略类
 */
@Service
public class BaseCoverStrategy implements CoverStrategy, InitializingBean {

    @Override
    public void download(String filepath, HttpServletResponse response)  {
        //封面的下载逻辑
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        CoverStrategyFactory.register("mp3", this);
        CoverStrategyFactory.register("flac", this);
    }
}

OggCoverStrategy ogg封面策略类：另一个实现了 CoverStrategy 接口的具体策略类，同样的在 Spring 初始化完成后把自身注册为 ogg 文件扩展名对应的策略。


/**
 * ogg格式的音频封面图片获取策略类
 */
@Service
public class OggCoverStrategy implements CoverStrategy, InitializingBean {

    @Override
    public void download(String filepath, HttpServletResponse response) {
         //封面的下载逻辑
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        CoverStrategyFactory.register("ogg", this);
    }
}

责任链设计模式

责任链模式在实际应用中常见的场景包括审批流程、日志记录、权限验证等。例如，一个用户提交了一个审批请求，可能需要经过多个审批人依次审批，每个审批人根据自身的权限和责任决定是否处理请求，直到找到能够处理请求的审批人为止。再比如我们有一个在线购物系统，用户下单后需要依次进行以下处理：库存检查、价格计算、优惠券验证、订单生成等。每个处理步骤都由不同的处理器来完成，而且处理器之间存在一定的逻辑关系。每个处理器负责处理一项具体的任务，并且决定是否将请求传递给下一个处理器。

在责任链模式中，通常有以下几个角色：

抽象处理者（Handler）： 定义了一个处理请求的接口，通常包含一个处理方法来处理请求，以及一个设置后继处理者的方法，用于构建责任链。

具体处理者（Concrete Handler）： 实现了抽象处理者定义的处理方法，并根据自身能力决定是否处理请求。如果自身无法处理请求，则将请求传递给下一个处理者。

客户端（Client）： 创建请求对象并将其发送给责任链的第一个处理者。它不关心处理细节和请求的传递过程，只需要知道如何创建请求对象和将请求发送给责任链即可。

案例:日志打印器

假设我们有一个日志记录器系统，它可以根据日志级别（如 INFO、DEBUG、ERROR）进行不同的处理。我们将使用责任链模式来实现这个系统。

1.定义日志级别
首先，定义不同的日志级别：

public class LogLevel {
    public static final int INFO = 1;
    public static final int DEBUG = 2;
    public static final int ERROR = 3;
}

2. 创建抽象日志记录器类

创建一个抽象类 Logger，它包含一个指向下一个处理器的引用以及一个处理日志请求的抽象方法：

public abstract class Logger {
    // 日志级别
    protected int level;

    // 责任链中的下一个处理器
    protected Logger nextLogger;

    // 设置责任链中的下一个处理器
    public void setNextLogger(Logger nextLogger) {
        this.nextLogger = nextLogger;
    }

    // 处理日志消息
    public void logMessage(int level, String message) {
        // 如果当前处理器的级别小于或等于消息的级别，则处理该消息
        if (this.level <= level) {
            write(message);
        }
        // 否则，传递给责任链中的下一个处理器
        else if (nextLogger != null) {
            nextLogger.logMessage(level, message);
        }
    }

    // 抽象方法，用于具体处理日志消息，由子类实现
    protected abstract void write(String message);
}

3. 创建具体的日志记录器类
实现具体的日志记录器类，它们分别处理不同级别的日志消息：

public class InfoLogger extends Logger {
    public InfoLogger(int level) {
        this.level = level;
    }

    @Override
    protected void write(String message) {
        System.out.println("INFO: " + message);
    }
}

public class DebugLogger extends Logger {
    public DebugLogger(int level) {
        this.level = level;
    }

    @Override
    protected void write(String message) {
        System.out.println("DEBUG: " + message);
    }
}

public class ErrorLogger extends Logger {
    public ErrorLogger(int level) {
        this.level = level;
    }

    @Override
    protected void write(String message) {
        System.out.println("ERROR: " + message);
    }
}

4. 创建责任链

public class LoggerChain {
    public static Logger getChainOfLoggers() {
        Logger errorLogger = new ErrorLogger(LogLevel.ERROR);
        Logger debugLogger = new DebugLogger(LogLevel.DEBUG);
        Logger infoLogger = new InfoLogger(LogLevel.INFO);

        infoLogger.setNextLogger(debugLogger);
        debugLogger.setNextLogger(errorLogger);

        return infoLogger;
    }
}

5.调用责任链

public class LoggerChain {
    // 静态方法，创建并返回日志处理器的责任链
    public static Logger getChainOfLoggers() {
        // 创建不同级别的日志处理器
        Logger errorLogger = new ErrorLogger(LogLevel.ERROR);  // 错误级别的日志处理器
        Logger debugLogger = new DebugLogger(LogLevel.DEBUG);  // 调试级别的日志处理器
        Logger infoLogger = new InfoLogger(LogLevel.INFO);     // 信息级别的日志处理器

        // 设置责任链：infoLogger -> debugLogger -> errorLogger
        infoLogger.setNextLogger(debugLogger);
        debugLogger.setNextLogger(errorLogger);

        // 返回责任链的第一个处理器
        return infoLogger;
    }
}

输出

INFO: This is an information.
DEBUG: This is a debug level information.
ERROR: This is an error information.

模板设计方法

模板设计模式（Template Method Pattern）是一种行为型设计模式，它定义了一个操作的算法骨架（模板），并允许子类在不改变算法结构的前提下对特定步骤进行实现或修改。这种模式在父类中定义了一个或多个抽象方法，子类通过重写这些方法来定制操作。

abstract class AbstractClass {
    // 模板方法
    public void templateMethod() {
        step1();
        step2();
        step3();
    }

    // 具体步骤
    private void step1() {
        System.out.println("具体步骤1");
    }

    // 抽象步骤，留给子类实现
    abstract void step2();

    // 具体步骤
    private void step3() {
        System.out.println("具体步骤3");
    }
}


class ConcreteClass extends AbstractClass {
    // 实现抽象步骤
    @Override
    void step2() {
        System.out.println("具体步骤2");
    }
}

public class TemplateMethodPatternDemo {
    public static void main(String[] args) {
        AbstractClass instance = new ConcreteClass();
        instance.templateMethod();  // 执行模板方法
    }
}

适配器模式

适配器模式有两种：对象适配器模式和类适配器模式。

  • 对象适配器模式: 基本思路与类适配器模式相同, 只是将 Adapter适配器类修改, 不是继承 Adaptee被适配者, 而是拥有 Adaptee类的实例, 以解决兼容性的问题。
  • 类适配器模式: Adapter适配器类, 继承 Adaptee被适配器类, 实现 Target目标类的接口, 完成适配。

以下举一个类适配器的例子：在生活中手机充电器, 需要将家用220V的交流电 转换为 5V的直流电后, 才能对手机充电

  • 手机充电器 相当于 Adapter适配器
  • 220V的交流电 相当于 Adaptee 被适配者
  • 5V的直流电 相当于 Target目标

Adapter适配器类, 继承 Adaptee被适配器类, 实现 Target目标类的接口, 完成适配。

Target目标接口: 输出5V电压

public interface Voltage5V {
    public int output5V();
}

Adaptee被适配器类: 220V电压。

public class Voltage220V {
    public int output220V() {
        System.out.println("正常220V电压");
        return 220;
    }
}

Adapter适配器类: 手机充电器 (将220V电压转换成 5V电压)

// Adapter适配器类: 将220V的交流电转换为5V的直流电
class VoltageAdapter extends Voltage220V implements Voltage5V {
    // 实现Voltage5V接口的方法，适配220V电压到5V
    @Override
    public int output5V() {
        // 获取220V的电压
        int voltage220V = output220V();
        // 转换为5V的电压
        int voltage5V = voltage220V / 44; // 220V 转换为 5V 的转换逻辑
        System.out.println("将220V电压转换为5V电压");
        return voltage5V;
    }
}


public class Main {
    public static void main(String[] args) {
        // 创建适配器对象
        Voltage5V adapter = new VoltageAdapter();
        // 使用适配器获取5V电压
        int voltage = adapter.output5V();
        System.out.println("手机充电器获得了" + voltage + "V的电压，为手机充电");
    }
}
  1. 适配器模式可以使得原本不兼容的接口能够相互协作，从而实现代码的复用。
  2. 增加了类的透明性和复用性，将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性
陈震_
关注
  • 13
    点赞
  • 踩
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Java 设计模式最佳实践
04-09
Java 设计模式最佳实践是软件开发中的重要主题，它涵盖了多种模式，这些模式已被广泛接受并应用于实际项目中，以解决常见的编程问题和提升代码的可读性、可维护性和可扩展性。在这个主题中，我们将深入探讨一些关键...
React设计模式和最佳实践 文字 pdf
09-12
React设计模式和最佳实践 文字 pdf
react设计模式和最佳实践
09-07
Facebook前端工程师15年一线开发经验凝结、深入讨论React核心模式与组建。
React 实战：设计模式和最佳实践1
08-04
Context，在第 8 小节会详细介绍。小结本节介绍了使用 React 的基本思想，希望读者能够学习到：1. 在 React 中，界面完全由数据驱动；2. 在
高性能设计模式最佳实践
01-17
高性能设计模式最佳实践
设计模式-责任链模式
明戈戈的博客
07-04 919
在该函数中为了实现对下家的引用，必须继承自 AbstractHandler，以实现对下家的引用，并提供getter/setter函数实现对该引用的取得和修改操作，这就是责任链的核心。由流管道的责任链模式也可以得出，凡是具有过滤和管道特征的应用都属于责任链器模式，例如 Java EE 中的 Filter 过滤器、UNIX中的管道符等，都属于责任链模式。因此，Java I/O 库中的所有输入流、输出流的类都采用了责任链模式，它们可以无限次地进行装饰转换，转换的目标就是得到自己想要的数据类型的流对象。
设计模式-模板方法模式
明戈戈的博客
07-02 1146
因为 HtpServlet.service()方法会检查请求方法是否调用了适当的处理方法，不必要覆盖 service()方法，只需覆盖相应的 do 方法就可以了。模板方法模式的使用方法：定义一个abstract的Class，在这个抽象类中，至少包括一个实现模板方法的不可被子类改写的public方法(需声明为final)，在这个公共方法中，实现模板方法的业务处理逻辑，同时，在这个方法中，还包括一些对本类中的抽象方法的调用：再根据业务的需要，定义各种不同的子类，并实现模板方法类的所有抽象方法。
Java中的设计模式在实际项目中的应用
微赚淘客开发者博客
07-05 378
设计模式是解决软件设计中常见问题的经验总结，它们提供了一种标准的解决方案，能够帮助开发人员设计出灵活、可扩展和易于维护的代码。在Java中，设计模式尤为重要，因为Java是一种面向对象的语言，设计模式可以帮助开发人员更好地利用面向对象编程的特性。通过合理应用设计模式，可以提高代码的复用性、灵活性和可维护性，降低项目的开发和维护成本，同时提升系统的可靠性和性能。观察者模式定义了对象之间的一对多依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新。对象，隐藏了对象的创建细节。
设计模式之单例模式
07-03 450
单例模式（Singleton Pattern）是一种常用的软件设计模式，它确保一个类仅有一个实例，并提供一个全局访问点来获取该实例。这个模式在多种场景下都非常有用，比如配置文件的读取、数据库连接、线程池等，这些资源通常只需要一个实例来管理，以避免资源浪费或数据不一致。
Go 依赖注入设计模式
最新发布
专注于全栈开发领域
07-06 985
依赖注入是一种强大的设计模式，可以帮助开发者编写更干净、更模块化的代码。虽然 Go 语言没有原生支持依赖注入，但通过手动实现、使用反射或利用第三方库，我们仍然可以在 Go 中有效地使用这一模式。选择哪种方法取决于你的具体需求和偏好，但无论如何，依赖注入都是提升 Go 开发效率的一个有力工具。
设计模式之策略模式
07-03 559
策略模式（Strategy Pattern）是一种行为设计模式，它定义了一系列算法，并将每一种算法封装起来，使它们可以相互替换。策略模式让算法的变化独立于使用算法的客户
API Object设计模式
NHB234567的博客
07-03 900
分层的好处立刻显现：1.API只允许通过的APIObject进行封装，那么在封装之前可以检索一下是否有封装了，如果有，进一步确认是否满足自己的调用需求，我们一般在测试API的时候一般各种参数验证，当API作为依赖接口调用的时候，一般参数比较少且固定，所以，API在封装的时候要兼顾到这两种情况。2.用例层只能通过APIObject的封装调用API，像登录token这种大部分接口会用到的信息，可以通过类初始化时传入，后续调用类下面方法的时候就不需要关心的。
java设计模式（三）——工厂方法模式
print_out的博客
07-01 146
在工厂方法模式中，不再使用简单工厂方法模式中那个静态工厂方法，而是为每一种要生产的产品配备一个工厂，每种工厂只生成一种特定产品，这样以后增加新产品时，直接新增对应的工厂就可以了，而不用修改原有的工厂。和简单工厂模式相比，工厂方法模式中，工厂类取代了简单工厂模式中的静态方法，如果需要扩展，比如要生产老北京布鞋第一步：定义具体产品类，继承产品抽象类。比如老北京布鞋(LaoBeiJIngShoes.class)第二步：定义具体产品工厂类，实现工厂类接口方法。
javascript 常见设计模式
qq_44376306的博客
07-01 851
在软件开发中，设计模式是解决特定问题的经验总结和可复用的解决方案。设计模式可以提高代码的复用性、可维护性和可读性，是提高开发效率的重要手段。
python解耦重构，提高程序维护性
07-03 335
重构代码，提高程序维护性
秒懂设计模式--学习笔记(7)【结构型-门面模式】
qq_28288835的博客
07-04 823
门面模式（Facade）可能是最简单的结构型设计模式它能将多个不同的子系统接口封装起来，并对外提供统一的高层接口，使复杂的子系统变得更易使用无论是“门”还是“面”，指代的都是某系统的外观部分，也就是与外界接触的临界面或接口，所以门面模式常常也被翻译为“外观模式”测试类文件封装了多个子系统，并将它们整合起来对外提供统一的访问接口SubSystemA、SubSystemB（子系统A、子系统B…）：隐藏于门面中的子系统，数量任意，且对外部不可见，专注于各自擅长的领域。如：蔬菜商类、厨师类、服务员类等。
设计模式之Command
07-03 396
Command模式，也称为行动模式或事务模式，用于将请求封装为一个对象，从而实现行为的解耦和灵活性。 这种模式特别适用于需要记录、撤销或重做操作的情况，因为它允许系统在运行时动态地处理请求。
设计模式简单示例
qq_38436431的博客
07-04 810
命令模式（Command Pattern）是一种行为型设计模式，又叫动作模式或事务模式。它将请求（命令）封装成对象，使得可以用不同的请求对客户端进行参数化，具体的请求可以在运行时更改、排队或记录，它讲发出者和接收者解耦本质：封装请求应用场景餐厅点餐：在一家餐厅中，服务员充当调用者，厨师充当接收者，菜品可以作为具体命令。当顾客想点菜时，服务员会将顾客的需求封装成一个命令对象，并传递给厨师。厨师根据命令对象中的信息来完成相应的烹饪工作。
设计模式之责任链模式
AOMGyz的博客
07-02 1002
责任链模式是将链中的每一个节点看做一个对象，每个节点处理的请求均不同，且内部自动维护一个指向下一个节点的引用。当一个请求从链的首端发出时，会沿着链的路径依次传递给每一个节点对象，直到有对象处理这个请求为止。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值