深入netty20-netty中的设计模式-建造者、策略、装饰者详解

m0_63833709

已于 2024-06-05 20:38:20 修改

阅读量881

点赞数 14

分类专栏：深入Netty 文章标签：设计模式 java 开发语言

于 2024-05-30 20:30:00 首次发布

本文链接：https://blog.csdn.net/m0_63833709/article/details/139324827

版权

深入Netty 专栏收录该内容

20 篇文章 1 订阅

订阅专栏

建造者模式

建造者模式（Builder Pattern）是一种对象创建型设计模式，用于构建一个复杂对象。这种模式通过将对象的构建过程与其表示分离，使得同样的构建过程可以创建出不同的表示。

建造者模式的主要特点：

分离构建和表示：将对象的构建过程和最终表示分离，使得用户不必知道对象构建的细节。
创建复杂对象：适用于创建具有多个属性的复杂对象。
相同的构建过程：不同的表示对象可以使用相同的构建过程。
控制对象的创建：通过一个导演类（Director）来控制构建过程，使得在运行时可以改变构建过程。
灵活性：用户可以逐步构建对象，并在任何时候获取对象的当前状态。

建造者模式的结构：

Builder（抽象建造者）：定义创建复杂对象的接口，包括建造各个部分的方法以及返回复杂对象的方法。
ConcreteBuilder（具体建造者）：实现抽象建造者接口，构建具体的对象，并提供方法返回最终的对象。
Product（产品角色）：表示被构建的复杂对象。
Director（导演角色）：负责构建过程的指挥，它使用具体建造者对象来创建产品的实例。

建造者模式的实现步骤：

定义产品类，即要构建的复杂对象。
定义抽象建造者类，声明建造各个部分的方法。
创建具体建造者类，实现抽象建造者类，并定义产品的组装过程。
定义导演类，用于构建对象的过程。
在客户端代码中，使用导演类和具体建造者类来构建对象。

建造者模式的适用场景：

当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
当构造过程允许有多种不同表示时。

建造者模式的缺点：

可能会创建过多的建造者类，因为每增加一个产品类，都需要增加一个建造者类。
可能会增加系统的复杂性，因为需要引入额外的类。

建造者模式在实际应用中的例子：

构建 SQL 语句：根据不同的条件构建不同的 SQL 语句。
构建复杂图形界面：在图形界面编程中，逐步构建复杂的界面布局。

建造者模式在 Netty 中的应用：

在 Netty 中，ServerBootstrap 和 Bootstrap 类是建造者模式的典型应用。这两个类用于初始化和配置服务器端和客户端的网络操作

// 创建 ServerBootstrap 实例
ServerBootstrap b = new ServerBootstrap();

// 设置线程池
b.group(new NioEventLoopGroup(1), new NioEventLoopGroup())
 .channel(NioServerSocketChannel.class) // 设置服务器端 Channel 类型
 .childHandler(new ChannelInitializer<SocketChannel>() {
     @Override
     public void initChannel(SocketChannel ch) {
         ch.pipeline().addLast(new MyServerHandler());
     }
 });

// 绑定端口并启动服务器
ChannelFuture f = b.bind(8080).sync();

在这个示例中，ServerBootstrap 使用了建造者模式来设置和启动服务器。通过链式调用，我们可以按顺序设置线程池、Channel 类型、ChannelHandler，以及绑定端口。这种方式使得配置过程非常直观和易于管理。

建造者模式的优势：

清晰的配置过程：通过链式调用，可以清晰地看到每一步配置，易于理解和维护。
灵活性：可以在运行时动态地修改配置。
减少错误：由于建造者模式提供了一种结构化的方式来构建复杂对象，因此减少了配置错误的可能性。
解耦：客户端不需要知道如何创建和组装对象，只需要通过建造者对象来获取最终的产品。

策略模式

策略模式（Strategy Pattern）是一种对象行为设计模式，它定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

策略模式的主要特点：

封装算法：将不同的算法封装在不同的策略类中。
替换算法：可以动态地替换对象的行为（算法）。
客户端控制：客户端可以控制运行时使用哪一个具体策略。
算法族：策略模式提供了管理相关的算法族的一种方式。
开闭原则：遵循开闭原则，当需要添加新的算法时，不需要修改现有的代码，只需要增加一个新的具体策略类。

策略模式的结构：

Strategy（策略接口）：定义所有支持的算法的公共接口。
ConcreteStrategy（具体策略）：实现策略接口，提供具体的算法实现。
Context（上下文）：使用策略接口作为属性，从而可以引用任意策略实现。
Client（客户端）：创建上下文对象，并设定具体的策略，然后通过上下文对象调用策略。

策略模式的实现步骤：

定义策略接口，声明执行算法的方法。
创建具体策略类，实现策略接口。
定义上下文类，包含策略接口类型的引用，并提供方法设置和执行策略。
在客户端代码中，创建上下文对象，注入具体策略，并执行。

策略模式的适用场景：

当需要在运行时选择使用多个算法中的某一个时。
当算法可能随时改变，或有新的算法需要添加时。

策略模式的缺点：

客户端必须知道所有的策略类，至少知道它们的类名，这可能会导致客户端与策略类耦合。
如果策略类数量过多，可能会导致系统难以管理和扩展。

策略模式在实际应用中的例子：

排序算法：根据不同的需求，动态选择不同的排序算法。
支付方式：不同的支付方式可以作为策略，用户可以根据需要选择。

策略模式在 Netty 中的应用：

在 Netty 中，EventExecutorChooser 接口及其实现类 DefaultEventExecutorChooserFactory 正是策略模式的一个应用实例。这个模式用于根据不同的条件选择不同的 EventExecutor 选择策略，从而优化线程分配和性能。

EventExecutorChooserFactory 和 EventExecutorChooser

EventExecutorChooserFactory 是一个工厂接口，用于创建 EventExecutorChooser 实例。EventExecutorChooser 接口定义了选择 EventExecutor 的策略。

DefaultEventExecutorChooserFactory 实现

DefaultEventExecutorChooserFactory 是 EventExecutorChooserFactory 的一个实现，提供了一个静态工厂方法 newChooser()，根据线程池大小是否为 2 的幂次方来选择不同的策略：

PowerOfTwoEventExecutorChooser：当线程池大小为 2 的幂次方时使用。在这种情况下，可以通过简单的位运算（模运算和位移）来选择线程，这种方法性能较高。
GenericEventExecutorChooser：当线程池大小不是 2 的幂次方时使用。这种选择器使用模运算来选择线程，但可能涉及更复杂的计算。

策略模式的应用

在 DefaultEventExecutorChooserFactory 的 newChooser() 方法中，根据线程池大小是否为 2 的幂次方，动态选择使用 PowerOfTwoEventExecutorChooser 或 GenericEventExecutorChooser：

public EventExecutorChooser newChooser(EventExecutor[] executors) {
    if (isPowerOfTwo(executors.length)) {
        return new PowerOfTwoEventExecutorChooser(executors);
    } else {
        return new GenericEventExecutorChooser(executors);
    }
}

策略模式的优势

灵活性：策略模式允许在运行时根据不同的条件选择不同的算法或行为。
扩展性：添加新的策略时，不需要修改现有代码，符合开闭原则。
解耦：策略的选择逻辑与使用策略的代码分离，降低了耦合度。

装饰者模式

装饰者模式（Decorator Pattern）是一种结构设计模式，允许用户在不改变对象自身的基础上，向一个对象添加新的功能。这种模式通过创建一个包装对象，也就是装饰者，来包裹实际对象。装饰者模式提供了一种灵活的替代方案，用于扩展或修改对象的行为，而不需要使用继承。

装饰者模式的主要特点：

动态添加职责：可以在运行时动态地给一个对象添加额外的职责。
透明性：装饰者模式不应当影响客户端使用原始类的方式。
灵活性：可以多个装饰者组合在一起，为一个对象添加多层职责。

装饰者模式的结构：

Component（抽象组件）：定义了一个接口，描述了可以动态添加的行为。
ConcreteComponent（具体组件）：实现抽象组件的具体类，也就是要装饰的具体对象。
Decorator（抽象装饰者）：抽象组件的抽象子类，持有组件的一个实例，并定义了相同接口。
ConcreteDecorator（具体装饰者）：抽象装饰者的具体子类，实现具体添加的行为。

装饰者模式的实现步骤：

定义一个接口，声明了要装饰的方法。
创建实现接口的具体类。
创建装饰者抽象类，实现接口，并持有接口的一个实例。
创建具体装饰者类，扩展装饰者抽象类，并添加额外的职责。
在客户端代码中，可以创建具体组件的实例，并通过装饰者来装饰它。

装饰者模式的适用场景：

当需要动态地给一个对象添加职责时。
当需要通过一种无需修改对象本身的方式扩展功能时。

装饰者模式的缺点：

过度使用装饰者模式可能导致设计过于复杂，难以理解。
多层装饰者嵌套可能导致难以追踪问题。

装饰者模式在实际应用中的例子：

咖啡例子：基础咖啡是具体组件，各种调料（如牛奶、摩卡、卡布奇诺等）是具体装饰者。
GUI 组件：基础组件（如按钮、文本框等）可以被多个装饰者装饰，以添加边框、颜色、事件监听等。

在 Netty 中，WrappedByteBuf 是一个装饰者模式的实现，它装饰了 ByteBuf 类，以便在不修改原始 ByteBuf 类的基础上添加额外的功能。ByteBuf 是 Netty 中用于处理字节数据的核心类。

装饰者模式在 Netty 中的应用：

WrappedByteBuf 作为装饰者基类：

WrappedByteBuf 类扩展了 ByteBuf 类，并持有一个 ByteBuf 类型的成员变量 buf，这个变量持有被装饰的 ByteBuf 实例。

protected final ByteBuf buf;
protected WrappedByteBuf(ByteBuf buf) {
    if (buf == null) {
        throw new NullPointerException("buf");
    }
    this.buf = buf;
}

在 WrappedByteBuf 的构造函数中，它接受一个 ByteBuf 实例，并将其赋值给 buf。这允许 WrappedByteBuf 委托 buf 来执行实际的 ByteBuf 操作。

UnreleasableByteBuf 和 SimpleLeakAwareByteBuf：

UnreleasableByteBuf 和 SimpleLeakAwareByteBuf 是 WrappedByteBuf 的子类，它们通过覆盖基类的方法来添加新的功能。

UnreleasableByteBuf：这个类覆盖了 release() 方法，使其总是返回 false，表示这个 ByteBuf 不应该被释放。这可以用于确保某些重要的 ByteBuf 实例在整个应用程序中保持活跃。

final class UnreleasableByteBuf extends WrappedByteBuf {
    // ... existing code ...
    @Override
    public boolean release() {
        return false;
    }
}

SimpleLeakAwareByteBuf：这个类可能添加了额外的逻辑来检测内存泄漏，例如跟踪引用计数或分配的内存量。

装饰者模式与代理模式的区别：

虽然装饰者模式和代理模式在某些方面看起来相似，它们都涉及到一个包装对象来提供额外的功能，但它们的关注点和使用场景有所不同：

目的：
- 装饰者模式：主要用于给一个对象添加额外的职责。装饰者可以在不修改对象自身的情况下，通过包装对象来扩展功能。
- 代理模式：主要用于在不直接访问实际对象的情况下，控制对实际对象的访问。代理可以在调用实际对象之前或之后添加额外的处理逻辑。
职责：
- 装饰者模式：通常只增加额外的职责，而不修改现有对象的行为。
- 代理模式：可以控制访问，并且可能改变对象的行为或逻辑。
使用场景：
- 装饰者模式：适用于需要动态地给对象添加职责，或者需要通过组合来创建更复杂对象的场景。
- 代理模式：适用于需要控制对对象的访问，或者需要在访问对象时执行额外操作的场景。