设计模式之八装饰者模式（结构型）

最新推荐文章于 2023-02-18 23:37:02 发布
最新推荐文章于 2023-02-18 23:37:02 发布
阅读量201 收藏
点赞数
分类专栏： 系统架构 # 设计模式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/heijunwei/article/details/115898244
版权

        前言：

        装饰模式是一种结构型设计模式， 允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。装饰器模式主要解决继承关系过于复杂的问题，通过组合来替代继承。它主要的作用是给原始类添加增强功能。这也是判断是否该用装饰器模式的一个重要的依据。除此之外，装饰器模式还有一个特点，那就是可以对原始类嵌套使用多个装饰器。为了满足这个应用场景，在设计的时候，装饰器类需要跟原始类继承相同的抽象类或者接口。

        

目录

一、结构

二、代码实现

三、装饰者在JDK中的应用

四、装饰模式适合应用场景

五、装饰模式优缺点

六、与其他模式的关系

 

一、结构

二、代码实现

装饰模式能够对敏感数据进行压缩和加密， 从而将数据从使用数据的代码中独立出来。

/**
 * @Description: 定义了读取和写入操作的通用数据接口
 *
 * @Author HJW
 * @Date 2021/4/20
 * @Version V1.0
 **/
public interface DataSource {
    void writeData(String data);

    String readData();
}


/**
 * @Description: 简单数据读写器
 *
 * @Author HJW
 * @Date 2021/4/20
 * @Version V1.0
 **/
public class FileDataSource implements DataSource{
    private String name;

    public FileDataSource(String name) {
        this.name = name;
    }

    @Override
    public void writeData(String data) {
        File file = new File(name);
        try (OutputStream fos = new FileOutputStream(file)) {
            fos.write(data.getBytes(), 0, data.length());
        } catch (IOException ex) {
            System.out.println(ex.getMessage());
        }
    }

    @Override
    public String readData() {
        char[] buffer = null;
        File file = new File(name);
        try (FileReader reader = new FileReader(file)) {
            buffer = new char[(int) file.length()];
            reader.read(buffer);
        } catch (IOException ex) {
            System.out.println(ex.getMessage());
        }
        return new String(buffer);
    }
}

/**
 * @Description: 抽象基础装饰
 *
 * @Author HJW
 * @Date 2021/4/20
 * @Version V1.0
 **/
public class DataSourceDecorator implements DataSource{
    private DataSource wrappee;

    DataSourceDecorator(DataSource source) {
        this.wrappee = source;
    }

    @Override
    public void writeData(String data) {
        wrappee.writeData(data);
    }

    @Override
    public String readData() {
        return wrappee.readData();
    }
}

/**
 * @Description: 压缩装饰
 *
 * @Author HJW
 * @Date 2021/4/20
 * @Version V1.0
 **/
public class CompressionDecorator extends DataSourceDecorator {
    private int compLevel = 6;

    public CompressionDecorator(DataSource source) {
        super(source);
    }

    public int getCompressionLevel() {
        return compLevel;
    }

    public void setCompressionLevel(int value) {
        compLevel = value;
    }

    @Override
    public void writeData(String data) {
        super.writeData(compress(data));
    }

    @Override
    public String readData() {
        return decompress(super.readData());
    }

    private String compress(String stringData) {
        byte[] data = stringData.getBytes();
        try {
            ByteArrayOutputStream bout = new ByteArrayOutputStream(512);
            DeflaterOutputStream dos = new DeflaterOutputStream(bout, new Deflater(compLevel));
            dos.write(data);
            dos.close();
            bout.close();
            return Base64.getEncoder().encodeToString(bout.toByteArray());
        } catch (IOException ex) {
            return null;
        }
    }

    private String decompress(String stringData) {
        byte[] data = Base64.getDecoder().decode(stringData);
        try {
            InputStream in = new ByteArrayInputStream(data);
            InflaterInputStream iin = new InflaterInputStream(in);
            ByteArrayOutputStream bout = new ByteArrayOutputStream(512);
            int b;
            while ((b = iin.read()) != -1) {
                bout.write(b);
            }
            in.close();
            iin.close();
            bout.close();
            return new String(bout.toByteArray());
        } catch (IOException ex) {
            return null;
        }
    }
}

/**
 * @Description: 加密装饰
 *
 * @Author HJW
 * @Date 2021/4/20
 * @Version V1.0
 **/
public class EncryptionDecorator extends DataSourceDecorator{
    public EncryptionDecorator(DataSource source) {
        super(source);
    }

    @Override
    public void writeData(String data) {
        super.writeData(encode(data));
    }

    @Override
    public String readData() {
        return decode(super.readData());
    }

    private String encode(String data) {
        byte[] result = data.getBytes();
        for (int i = 0; i < result.length; i++) {
            result[i] += (byte) 1;
        }
        return Base64.getEncoder().encodeToString(result);
    }

    private String decode(String data) {
        byte[] result = Base64.getDecoder().decode(data);
        for (int i = 0; i < result.length; i++) {
            result[i] -= (byte) 1;
        }
        return new String(result);
    }
}

/**
 * @Description: 客户端测试
 *
 * @Author HJW
 * @Date 2021/4/20
 * @Version V1.0
 **/
public class Client {
    public static void main(String[] args) {
        String decorator = "装饰者模式魅力无限";
        DataSourceDecorator encoded = new CompressionDecorator(
            new EncryptionDecorator(
                new FileDataSource("out/OutputDemo.txt")));
        encoded.writeData(decorator);
        DataSource plain = new FileDataSource("out/OutputDemo.txt");

        System.out.println("- Input ----------------");
        System.out.println(decorator);
        System.out.println("- Encoded --------------");
        System.out.println(plain.readData());
        System.out.println("- Decoded --------------");
        System.out.println(encoded.readData());
    }

}

三、装饰者在JDK中的应用

详细解析装饰者模式在io中的应用：

 


InputStream in = new FileInputStream("/hjw/test.txt");
InputStream buffer= new BufferedInputStream(in);
byte[] data = new byte[128];
while (buffer.read(data) != -1) {
  //...
}

        初看上面的代码，我们会觉得 Java IO 的用法比较麻烦，需要先创建一个 FileInputStream 对象，然后再传递给 BufferedInputStream 对象来使用。那么Java IO 为什么不设计一个继承 FileInputStream 并且支持缓存的 BufferedFileInputStream 类呢？这样我们就可以像下面的代码中这样，直接创建一个 BufferedFileInputStream 类对象，打开文件读取数据，用起来岂不是更加简单？

       如果 InputStream 只有一个子类 FileInputStream 的话，那我们在 FileInputStream 基础之上，再设计一个孙子类 BufferedFileInputStream，也算是可以接受的，毕竟继承结构还算简单。但实际上，继承 InputStream 的子类有很多。我们需要给每一个 InputStream 的子类，再继续派生支持缓存读取的子类。除了支持缓存读取之外，如果我们还需要对功能进行其他方面的增强，比如下面的 DataInputStream 类，支持按照基本数据类型（int、boolean、long 等）来读取数据。

       在这种情况下，如果我们继续按照继承的方式来实现的话，就需要再继续派生出 DataFileInputStream、DataPipedInputStream 等类。如果我们还需要既支持缓存、又支持按照基本类型读取数据的类，那就要再继续派生出 BufferedDataFileInputStream、BufferedDataPipedInputStream 等 n 多类。这还只是附加了两个增强功能，如果我们需要附加更多的增强功能，那就会导致组合爆炸，类继承结构变得无比复杂，代码既不好扩展，也不好维护。

      IO基于装饰者模式的设计方案:


public abstract class InputStream {
  //...
  public int read(byte b[]) throws IOException {
    return read(b, 0, b.length);
  }
  
  public int read(byte b[], int off, int len) throws IOException {
    //...
  }
  
  public long skip(long n) throws IOException {
    //...
  }

  public int available() throws IOException {
    return 0;
  }
  
  public void close() throws IOException {}

  public synchronized void mark(int readlimit) {}
    
  public synchronized void reset() throws IOException {
    throw new IOException("mark/reset not supported");
  }

  public boolean markSupported() {
    return false;
  }
}

public class BufferedInputStream extends InputStream {
  protected volatile InputStream in;

  protected BufferedInputStream(InputStream in) {
    this.in = in;
  }
  
  //...实现基于缓存的读数据接口...  
}

public class DataInputStream extends InputStream {
  protected volatile InputStream in;

  protected DataInputStream(InputStream in) {
    this.in = in;
  }
  
  //...实现读取基本类型数据的接口
}

        从 Java IO 的设计来看，装饰器模式相对于简单的组合关系，还有两个比较特殊的地方。第一个比较特殊的地方是：装饰器类和原始类继承同样的父类，这样我们可以对原始类“嵌套”多个装饰器类。比如，下面这样一段代码，我们对 FileInputStream 嵌套了两个装饰器类：BufferedInputStream 和 DataInputStream，让它既支持缓存读取，又支持按照基本数据类型来读取数据。  


InputStream in = new FileInputStream("/hjw/test.txt");
InputStream buffer= new BufferedInputStream(in);
DataInputStream din = new DataInputStream(buffer);
int data = din.readInt();

第二个比较特殊的地方是：装饰器类是对功能的增强，这也是装饰器模式应用场景的一个重要特点。实际上，符合“组合关系”这种代码结构的设计模式有很多，比如代理模式、桥接模式，还有现在的装饰器模式。尽管它们的代码结构很相似，但是每种设计模式的意图是不同的。就拿比较相似的代理模式和装饰器模式来说吧，代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。     

        实际上，如果去查看 JDK 的源码，你会发现，BufferedInputStream、DataInputStream 并非继承自 InputStream，而是另外一个叫 FilterInputStream 的类。那这又是出于什么样的设计意图，才引入这样一个类呢？我们再重新来看一下 BufferedInputStream 类的代码。InputStream 是一个抽象类而非接口，而且它的大部分函数（比如 read()、available()）都有默认实现，按理来说，我们只需要在 BufferedInputStream 类中重新实现那些需要增加缓存功能的函数就可以了，其他函数继承 InputStream 的默认实现。但实际上，这样做是行不通的。对于即便是不需要增加缓存功能的函数来说，BufferedInputStream 还是必须把它重新实现一遍，简单包裹对 InputStream 对象的函数调用。具体的代码示例如下所示。如果不重新实现，那 BufferedInputStream 类就无法将最终读取数据的任务，委托给传递进来的 InputStream 对象来完成。???


public class BufferedInputStream extends InputStream {
  protected volatile InputStream in;

  protected BufferedInputStream(InputStream in) {
    this.in = in;
  }
  
  // f()函数不需要增强，只是重新调用一下InputStream in对象的f()
  public void f() {
    in.f();
  }  
}

        实际上，DataInputStream 也存在跟 BufferedInputStream 同样的问题。为了避免代码重复，Java IO 抽象出了一个装饰器父类 FilterInputStream，代码实现如下所示。InputStream 的所有的装饰器类（BufferedInputStream、DataInputStream）都继承自这个装饰器父类。这样，装饰器类只需要实现它需要增强的方法就可以了，其他方法继承装饰器父类的默认实现。


public class FilterInputStream extends InputStream {
  protected volatile InputStream in;

  protected FilterInputStream(InputStream in) {
    this.in = in;
  }

  public int read() throws IOException {
    return in.read();
  }

  public int read(byte b[]) throws IOException {
    return read(b, 0, b.length);
  }
   
  public int read(byte b[], int off, int len) throws IOException {
    return in.read(b, off, len);
  }

  public long skip(long n) throws IOException {
    return in.skip(n);
  }

  public int available() throws IOException {
    return in.available();
  }

  public void close() throws IOException {
    in.close();
  }

  public synchronized void mark(int readlimit) {
    in.mark(readlimit);
  }

  public synchronized void reset() throws IOException {
    in.reset();
  }

  public boolean markSupported() {
    return in.markSupported();
  }
}

  总结：      

  

  • Java的IO结构，FilterInputStream就是一个装饰者
public abstract class InputStream implements Closeable{} //是一个抽象类，即Component   
public class FilterInputStream extends InputStream { //是一个装饰者类Decorator      
    protected volatile InputStream in//被装饰的对象 }

class DataInputStream extends FilterInputStream implements DataInput {//FilterInputStream 子类，也继承了被装饰的对象}
public class Decorator {

	public static void main(String[] args) throws Exception{
	
		//说明
		//1. InputStream 是抽象类
		//2. FileInputStream 是  InputStream 子类
		//3. FilterInputStream  是  InputStream 子类
		//4. DataInputStream 是 FilterInputStream 子类，具体的修饰者
		//5. FilterInputStream 类 有  protected volatile InputStream in; 即含被装饰者
		//6. 分析得出在jdk 的io体系中，就是使用装饰者模式
		
		DataInputStream dis = new DataInputStream(new FileInputStream("d:\\abc.txt"));
		System.out.println(dis.read());
		dis.close();
	}

}

四、装饰模式适合应用场景

  •  如果你希望在无需修改代码的情况下即可使用对象， 且希望在运行时为对象新增额外的行为， 可以使用装饰模式。

        装饰能将业务逻辑组织为层次结构， 可为各层创建一个装饰， 在运行时将各种不同逻辑组合成对象。 由于这些对象都遵循通用接口， 客户端代码能以相同的方式使用这些对象。

  •  如果用继承来扩展对象行为的方案难以实现或者根本不可行， 你可以使用该模式。

         许多编程语言使用 final最终关键字来限制对某个类的进一步扩展。 复用最终类已有行为的唯一方法是使用装饰模式： 用封装器对其进行封装。

五、装饰模式优缺点

  •  无需创建新子类即可扩展对象的行为。
  •  可以在运行时添加或删除对象的功能。
  •  可以用多个装饰封装对象来组合几种行为。
  •  单一职责原则。 可以将实现了许多不同行为的一个大类拆分为多个较小的类。
  •  XXX 在封装器栈中删除特定封装器比较困难。
  •  XXX实现行为不受装饰栈顺序影响的装饰比较困难。
  •  XXX各层的初始化配置代码看上去可能会很糟糕。

六、与其他模式的关系

  • 适配器模式可以对已有对象的接口进行修改， 装饰模式则能在不改变对象接口的前提下强化对象功能。 此外， 装饰还支持递归组合， 适配器则无法实现。

  • 适配器能为被封装对象提供不同的接口， 代理模式能为对象提供相同的接口， 装饰则能为对象提供加强的接口。

  • 责任链模式和装饰模式的类结构非常相似。 两者都依赖递归组合将需要执行的操作传递给一系列对象。 但是， 两者有几点重要的不同之处。

    责任链的管理者可以相互独立地执行一切操作， 还可以随时停止传递请求。 另一方面， 各种装饰可以在遵循基本接口的情况下扩展对象的行为。 此外， 装饰无法中断请求的传递。

  • 组合模式和装饰的结构图很相似， 因为两者都依赖递归组合来组织无限数量的对象。

    装饰类似于组合， 但其只有一个子组件。 此外还有一个明显不同： 装饰为被封装对象添加了额外的职责， 组合仅对其子节点的结果进行了 “求和”。

    但是， 模式也可以相互合作： 你可以使用装饰来扩展组合树中特定对象的行为。

  • 大量使用组合和装饰的设计通常可从对于原型模式的使用中获益。 你可以通过该模式来复制复杂结构， 而非从零开始重新构造。

  • 装饰可让你更改对象的外表， 策略模式则让你能够改变其本质。

  • 装饰和代理有着相似的结构， 但是其意图却非常不同。 这两个模式的构建都基于组合原则， 也就是说一个对象应该将部分工作委派给另一个对象。 两者之间的不同之处在于代理通常自行管理其服务对象的生命周期， 而装饰的生成则总是由客户端进行控制。

 

 

 

     

 

 

 

心灵彼岸-诗和远方
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
寂然解读设计模式 - 装饰者模式
weixin_44808014的博客
01-06 222
I walk very slowly, but I never walk backwards 设计模式 - 装饰者模式 寂然 大家好，我是寂然，本节课，我们来聊设计模式中的装饰者模式，当然，首先，来一杯塞纳河畔，左岸的咖啡☕️ 案例需求 - 星巴克咖啡 来看一个星巴克咖啡订单项目需求： 咖啡种类/单品咖啡：Espresso（意大利浓咖啡）、Cappuccino（卡布奇诺）、Cafe Latte（冰拿铁） 配料：Milk、sugar 客户可以点单品咖啡，也可以单品咖啡+配料，根据客户订单计算
设计模式之结构型模式
12-15
桥接模式之消息发送、适配器模式之购物车商品推荐、装饰者模式之相亲（男人的描述）、组合模式之对购物网站、享元模式之网店模板
设计模式 -＞ 装饰者模式
rod0320的博客
03-08 322
装饰者模式 装饰者模式，指在不改变现有对象结构的情况下，动态的给对象添加一些额外的职责。 装饰者模式用于扩展对象的功能，用于代替继承扩展的方式 装饰者模式就是一种简单的包装逻辑,把你要包装的类传入装饰者类 装饰者类围绕要包装的类做功能的添加 实现 -> 要灵活使用,并不是说一定要一个接口什么的 一个接口,一个实现接口的主类,实现接口的抽象装饰类,具体的装饰类 我们用Java中InputStream举例 接口 -> InputStream: 是一个抽象类 被装饰者类 -&
设计模式-结构型模式：装饰模式
逐梦苍穹的博客
02-18 364
介绍设计模式之装饰模式(Decorator Pattern)，这是一种结构型设计模式，它允许动态地向对象添加额外的职责，同时又不会影响到从这个对象派生出的其他对象。
java输入输出流03
weixin_44251806的博客
08-03 391
字符流字节流交互使用
装饰器模式
今晨的个人博客
01-12 134
装饰器模式 Decorator Pattern 在不改变原有类的基础上，给其增加新的功能。就像人们冬天穿棉袄，夏天穿短袖，以应对不同的需求，而人本身并没有改变，只给其增加不同的装饰来满足不同的需求。 装饰器类需要继承原有类的同时还要关联原有类，并在有参构造中传入原有类。 FilterInputStream就是一个装饰器类。想对InputStream进行扩展增加一些功能，使用装饰器模式对InputStream进行关联 public class FilterInputStream extends InputSt
23种设计模式——装饰者模式
万里顾一程的博客
11-17 4072
文章目录23种设计模式——装饰者模式1、装饰者模式概述2、装饰者模式的结构3、装饰者模式的实现4、装饰者模式的应用场景 23种设计模式——装饰者模式 1、装饰者模式概述 背景 有些人为了早上多睡一会，就会用方便的方式解决早餐问题。有些人早餐可能会吃煎饼，煎饼中可以加鸡蛋，也可以加香肠，但是不管怎么“加码”，都还是一个煎饼。在现实生活中，常常需要对现有产品增加新的功能或美化其外观，如房子装修、相片加相框、咖啡加调料等，都是装饰器模式。 装饰者模式的定义 装饰者（Decorator）模式的定义：指在不改
设计模式~~~装饰者模式
PeakGao
10-13 1641
学习难度：※※※ 使用频率：※※※ 上班族大多都有睡懒觉的习惯，每天早上上班时间都很紧张，于是很多人为了多睡一会，就会用方便的方式解决早餐问题。有些人早餐可能会吃煎饼，煎饼中可以加鸡蛋，也可以加香肠，但是不管怎么“加码”，都还是一个煎饼。在现实生活中，常常需要对现有产品增加新的功能或美化其外观，如房子装修、相片加相框等，都是装饰器模式。 在软件开发过程中，有时想用一些现存的组件。这些组件可能只是完成了一些核心功能。但在不改变其结构的情况下，可以动态地扩展其功能。所有这些都可以釆用装饰模式来实现。 一
装饰者模式设计android,设计模式之装饰者模式
weixin_35406877的博客
06-01 92
作用动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(OCP)。原理打包快递。主体-被装饰者：陶瓷、衣服包装-装饰者：纸板、塑料袋案例装饰者继承被装饰者，并且聚合被装饰者。被装饰者public abstract class Drink {private String desc;private float price;public abstract flo...
设计模式-装饰者模式
weixin_39690861的博客
03-09 143
io中的装饰者 1.inputstream是抽象类，是一个基类 2.FileInputStream是inputstream的子类，是具体的被装饰者 3.FilterInputStream是inputstream的子类，是装饰者的基类，类似咖啡样例中的Decorate类 4.DataInputStream是FilterInputStream的子类，是具体的装饰者，类似咖啡样例中的Milk 5.FilterInputStream中有protected volatile InputStream in;即...
javaI/O之BufferedInputStream
热门推荐
博学而笃志，切问而近思
10-06 1万+
javaI/O之BufferedInputStream   javaI/O之BufferedInputStream 一、介绍     BufferedInputStream类继承了FilterInputStream对象，是inputStream的修饰者类。能够将输入流先进行缓存，避免每次都需要进行实质性的I/O操作。第一次会缓存8192字节的数据，然后会成倍增长。 二、属性     p
c++设计模式-结构型模式-装饰器模式
06-12
c++设计模式-结构型模式-装饰器模式；QT工程；c++简单源码； 装饰器（Decorator）模式的定义：指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。
软件设计模式结构型模式实验代码
01-08
发送消息通知，比如订货发货通知等），适配器模式（电子商务网站有购物车的功能，可以把挑选的东西加入购物车，可以把挑选的东西加入购物车、删除或者更改购买数量，并对多个商品进行一次性结算），装饰者模式（这是...
JAVA-设计模式-结构型模式-装饰模式
08-10
JAVA-设计模式-结构型模式-装饰模式
设计模式结构型模式
02-24
本文来自cnblogs，文章主要总结了适配器模式、桥接模式、组合模式、装饰模式以及外观模式等的相关内容。Target（目标抽象类）：目标抽象类定义客户所需接口，可以是一个抽象类或接口，也可以是具体类。Adapter...
结构型模式02-装饰者模式（动态为一个对象添加职责，就增加功能而言，装饰模式比生成子类更加灵活）
Difffate的技术随笔
04-27 1669
装饰者模式，名字很贴切，装饰一词，本来就是在原有的基础上增添点东西。而在软件领域，增加功能是一件多么常见的事情。策划最常说的就是，“你看下，这里能不能加个.....”，QA的绩效考核上，还要包含建议数目，如果都要完成这些建议，那么开发的工作量可能就翻了一倍哈哈哈。 对比继承方式带来的强依赖而言，以及父类变更对子类的影响之大，装饰者取了巧，虽然从抽象意义上，装饰者不是事实意义上的“孩子”类（或者说
装饰者模式-JDK中InputStream和HttpServletRequsetWrapper源码分析
weixin_30685047的博客
04-17 118
1 装饰模式概念 1.1 装饰者模式定义 定义:装饰模式的基本含义是能够动态地为一个对象添加一些额外的行为职责。 谈到对象行为职责的扩展，我们很容易就能够想到面向对象编程语言的一个重要特征：集成。继承是绝大多数面向对象的...
装饰者模式（结构型）
小憩一下
02-28 300
一：相关定义装饰者模式：动态的将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。二：具体的类图和示例装饰者模式类图：component是我们要装饰的组件，decorator是我们的装饰器，在这里继承要装饰的组件（使用装饰的目的就是拓展功能而不改变原有的代码；这样，我们新增一个装饰者，客户端依然可以调用原有的组件接口来使用我们的扩展了功能的对象）。ConcreteDecorat...
设计模式之装饰者模式
weixin_30596735的博客
09-22 165
　　今天我们来学习一下装饰者模式。作为一名程序猿，相信许多人都跟我一样，在平时写代码的过程中，习惯使用继承。但是继承有时候会出现非常严重的问题，不过，没担心。装饰者模式将会给爱用继承的我们一个全新的设计眼界！ 一、星巴兹咖啡的故事 　　我们通过一个生动有趣的例子来引出我们今天的主角--装饰者模式。 　　1、现在呢，有一个咖啡馆，它有一套自己的订单系统，当顾客来咖啡馆的时候，可以通过...
结构型设计模式与行为型设计模式之间的关联
最新发布
11-30
例如，中介者模式是一种行为型设计模式，但它通常需要与其他结构型设计模式如组合模式一起使用，以实现更复杂的系统结构。 4. 组合使用：在实际应用中，结构型设计模式和行为型设计模式通常需要组合使用，以实现更...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值