当前位置： 首页 > news >正文

设计模式2

news 2024/12/19 21:33:19

23中设计模式分类

创建型模式：对象实例化的模式，创建型模式用于解耦对象的实例化过程。（对象的创建和对象的使用分离）

  • 5种：单例模式、工厂模式、抽象工厂模式、原型模式、建造者模式

结构型模式：把类或对象结合在一起形成一个更大的结构。（就像搭积木）

  • 7种：适配器、桥接、装饰、组合、外观、享元、代理

行为型模式：类和对象如何交互，及划分责任和算法。（关注类和对象的结构，它们之间的相互作用）

  • 11种：模板方法、命令、访问者、迭代器、观察者、中介、备忘录、解释器、状态、策咯、责任链模式

根据作用范围来分

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

  1. 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。

    • 工厂方法、（类）适配器、模板方法、解释器属于该模式。

  2. 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。

范围\目的创建型模式结构型模式行为型模式
类模式工厂方法(类）适配器模板方法、解释器
对象模式单例 原型 抽象工厂 建造者代理 (对象）适配器 桥接 装饰 外观 享元 组合策略 命令 职责链 状态 观察者 中介者 迭代器 访问者 备忘录

创建型（用于描述“怎么创建对象”，它的特点时“将对象创建和使用分离”）

  • 创建型模式 (Creational Pattern) 对类的实例化过程进 行了抽象，能够 将软件模块中对象的创建和对象的使用 分离 。

  • 为了使软件的结构更加清晰，外界对于这些对象 只需要知道它们共同的接口，而不清楚其具体的实现细 节，使整个系统的设计更加符合单一职责原则。 创建型模式在 创建什么 (What) ， 由谁创建 (Who) ， 何时创建 (When) 等方面都为软件设计者提供了尽可能大 的灵活性。

  • 创建型模式 隐藏了类的实例的创建细节，通 过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的 。

结构型（将对象和类组装成比较大的结构，并同时保持结构的灵活和高效。）

  • 其描述 如何将类或者对 象结合在一起形成更大的结构 ，就像搭积木，可以通过 简单积木的组合形成复杂的、功能更为强大的结构。

  • 结构型模式可以分为 类结构型模式 和 对象结构型模式 ：

    • 类结构型模式关心类的组合 ，由多个类可以组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系。

    • 对象结构型模式关心类与对象的组合，通过关联关系使得在一个类中定义另一个类的实例对象，然后通过该对象调用其方法。 根据“合成复用原则”，在系统中尽量使用关联关系来替代继承关系，因此大部分结构型模式都是 对象结构型模式 。

行为型（负责对象间的高效沟通和职责委派）

  • 行为型模式 (Behavioral Pattern) 是对 在不 同的对象之间划分责任和算法的抽象化 。

  • 行为型模式不仅仅关注类和对象的结构，而 且 重点关注它们之间的相互作用 。 通过行为型模式，可以更加清晰地 划分类与 对象的职责 ，并 研究系统在运行时实例对象 之间的交互 。在系统运行时，对象并不是孤 立的，它们可以通过相互通信与协作完成某 些复杂功能，一个对象在运行时也将影响到 其他对象的运行。

  • 行为型模式分为 类行为型模式 和 对象行为型模式 两种： • 类行为型模式 ：类的行为型模式 使用继承关系在几个类之间分配行为 ，类行为型模式主要通过多态等方式来分配父类与子类的职责。 • 对象行为型模式 ：对象的行为型模式则 使用对象的聚合关联关系来分配行为 ，对象行为型模式主要是通过对象关联等方式来分配两个或多个类的职责。根据“合成复用原则”，系统中要尽量使用关联关系来取代继承关系，因此大部分行为型设计模式都属于对象行为型设计模式 。

创建型 (Creational)

  • 抽象工厂模式(Abstract Factory)

  • 工厂方法模式(Factory Method)

  • 建造者模式(Builder)

  • 原型模式(Prototype)

  • 单例模式(Singleton)

对象的创建和使用分离（对象实例化模式，用于解耦对象实例化过程）。

单例模式(Singleton)

定义：某个类只能生成一个实例，该类提供一个全局访问点，供外部获取该实例。其拓展是有限多例模式

  • 保证一个实例对象。

优点：只有一个实例，节约了内存资源，提高系统性能；(减少系统的性能开销)

缺点：

没有抽象层，不能扩展

职责过重，在一定程度上，违背了单一原则

应用：数据库连接池、springbean单例

场景:

对于一般频繁创建和销毁对象的可以使用单例模式，不牵扯线程安全

Spring IOC容器中的 Bean 默认就是单例。

Spring Boot 中的 Controller、Service、Dao 层中通过 @Autowire的依赖注⼊对象默认都是单例的。

1、饿汉式（线程安全）

2、懒汉式（线程不安全）

双重检查锁dcl(doubleCheckLock)、synchronized

3、静态内部类

4、枚举

饿汉式

直接创建对象，不存在线程安全问题。

之所以叫饿汉式，不论用不用这个类的对象，只要加载类的时候就会创建出来这个类的一个对象（内存浪费 ）。

使用饿汉式对象在类加载的时候就会被创建。

使用类名.静态方法 获取到类的唯一对象。

  1. 静态常量方式

  2. 静态代码块方式

优点：没有加锁，执行效率会提高。

缺点：类加载时就初始化，浪费内存。

创建的过程

1．构造器私有

2．私有静态实例引用

3．对外提供获取该实例的静态共有方法

public class EagerSingleton {// 1、私有构造函数，防止外部实例化private EagerSingleton() {}// 2、私有静态实例，在类加载时就初始化private static final EagerSingleton instance = new EagerSingleton();// 3、提供一个公共静态方法，返回实例对象public static EagerSingleton getInstance() {return instance;}public static void main(String[] args) {EagerSingleton instance1 = EagerSingleton.getInstance();EagerSingleton instance2 = EagerSingleton.getInstance();//trueSystem.out.println(instance1 == instance2);//trueSystem.out.println(instance1.hashCode() == instance2.hashCode());}
}

步骤如下：

1、构造器私有化（防止 new）

2、类的内部创建对象

3、向外暴露一个静态的公共方法。 getInstance

4、代码实现

懒汉式(双检锁volatile synchronized)

懒加载，延迟创建对象，需要用的时候再创建对象。

public final class Singleton {
​private Singleton() { }
​// 问题1：解释为什么要加 volatile ?private static volatile Singleton INSTANCE = null;
​// 问题2：对比实现3, 说出这样做的意义 public static Singleton getInstance() {
​if (INSTANCE != null) {return INSTANCE;}
​synchronized (Singleton.class) {// 问题3：为什么还要在这里加为空判断, 之前不是判断过了吗if (INSTANCE != null) { // t2 return INSTANCE;}INSTANCE = new Singleton();return INSTANCE;}}
}

静态内部类形式、枚举

java单例模式：饿汉式、懒汉式_饿汉模式类图-CSDN博客

拓展：多例设计模式

单例设计模式只留下一个类的一个实例化对象，而多例设计模式，会定义出多个对象。例如：定义一个表示星期的操作类，这个类的对象只能有7个实例化对象（星期一 ~ 星期日）；定义一个表示性别的类，只能有2个实例化对象（男、女）；定义一个表示颜色的操作类，只能有3个实例化对象（红、绿、蓝）。这种情况下，这样的类就不应该由用户无限制地去创造实例化对象，应该只使用有限的几个，这个就属于多例设计模式。不管是单例设计模式还是多例设计模式，有一个核心不可动摇，即构造器方法私有化。

class Sex{private String title;private static final Sex MALE = new Sex("男");private static final Sex FEMALE = new Sex("女");private Sex(String title){        //构造器私有化this.title = title;}public String toString(){return this.title;}public static Sex getInstance(int ch){switch(ch){case 1:return MALE;case 2:return FEMALE;default:return null;}}
}public class TestDemo{public static void main(String args[]){Sex sex = Sex.getInstance(2);System.out.println(sex);}
}==========程序执行结果=========
女

工厂模式(Factory)

  • 定义一个用于创建对象接口，让子类决定实例化哪一类

  • 使一个类实例化延迟到其子类。

  • 生产对象。

简单工厂： 根据传的对象类型，生成不同对象。

[实现一个需求：客户可以点任意口味的披萨，奶酪披萨、胡椒等等。]

工厂方法： 在简单工厂基础上支持扩展，添加对应工厂类；

都是同一类；

抽象工厂： 可以生产一个产品族；一个接口，多个抽象类，然后是N个实现类。

抽象产品类，产品实现类，抽象工厂类，有M个产品等级就应该有M个实现工厂类。

为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。

应用：spring bean工厂

1、普通工厂模式

建立一个工厂类，对实现同一接口的一些类进行实例的创建。

举例如下：（我们举一个发送邮件和短信的例子）

首先，创建二者的共同接口：

public interface Sender {public void Send();
}

其次，创建实现类：

public class MailSender implements Sender {@Overridepublic void Send() {System.out.println("this is mailsender!");}
}
public class SmsSender implements Sender {@Overridepublic void Send() {System.out.println("this is sms sender!");}
}

最后，建工厂类：

public class SendFactory {public Sender produce(String type) {if ("mail".equals(type)) {return new MailSender();} else if ("sms".equals(type)) {return new SmsSender();} else {System.out.println("请输入正确的类型!");return null;}}
}

我们来测试下：

public class FactoryTest {public static void main(String[] args) {SendFactory factory = new SendFactory();Sender sender = factory.produce("sms");sender.Send();}
​
}

输出：this is sms sender!

2、多个工厂方法模式

是对普通工厂方法模式的改进，在普通工厂方法模式中，如果传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。关系图：

将上面的代码做下修改，改动下SendFactory类就行，如下：

public class SendFactory {public Sender produceMail(){return new MailSender();}public Sender produceSms(){return new SmsSender();}
}

测试类如下：

public class FactoryTest {public static void main(String[] args) {SendFactory factory = new SendFactory();Sender sender = factory.produceMail();sender.Send();}
}

输出：this is mailsender!

3、静态工厂方法模式

将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。

public class SendFactory {public static Sender produceMail(){return new MailSender();}public static Sender produceSms(){return new SmsSender();}
}
public class FactoryTest {public static void main(String[] args) {    Sender sender = SendFactory.produceMail();sender.Send();}
}

输出：this is mailsender!

总体来说，工厂模式适合：凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。

在以上的三种模式中，第一种如果传入的字符串有误，不能正确创建对象，第三种相对于第二种，不需要实例化工厂类，

所以，大多数情况下，我们会选用第三种——静态工厂方法模式。

好处：客户端不需要创建对象，明确了各个类的职责 缺点：该工厂类负责创建所有实例，如果有新的类加入，需要不断的修改工厂类，不利于后期的维护

抽象工厂模式

工厂方法模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，

所以，从设计角度考虑，有一定的问题，如何解决？

就用到抽象工厂模式，创建多个工厂类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

因为抽象工厂不太好理解，我们先看看图，然后就和代码，就比较容易理解。

请看例子：

定义个Sender接口

public interface Sender {public void Send();
}

两个实现类：

public class MailSender implements Sender {@Overridepublic void Send() {System.out.println("this is mailsender!");}
}
public class SmsSender implements Sender {@Overridepublic void Send() {System.out.println("this is SmsSender!");}
}

在提供一个接口：

public interface Provider {public Sender produce();
}

两个工厂类：

public class SendMailFactory implements Provider {@Overridepublic Sender produce(){return new MailSender();}}
public class SendSmsFactory implements Provider{@Overridepublic Sender produce() {return new SmsSender();}
}

测试类：

public class Test {public static void main(String[] args) {Provider provider = new SendMailFactory();Sender sender = provider.produce();sender.Send();}
}

其实这个模式的好处就是，如果你现在想增加一个功能：发另一种信息，则只需做一个实现类，实现Sender接口，

同时做一个工厂类，实现Provider接口，就OK了，无需去改动现成的代码。这样做，拓展性较好！

  • 好处：如果有新的类进来，只需要添加一个对应的具体工厂类，不影响现有代码，增加了程序的扩展性

  • 缺点：增加了代码量

原型模式(Prototype)

思想：就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。

批量创建对象。

浅复制：将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的。

深复制：将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。简单来说，就是深复制进行了完全彻底的复制，而浅复制不彻底。

浅拷贝:只会复制原型对象，但不会复制它所引用的对象。

深拷贝：将原型对象中所有类型，无论是值类型还是引用类型，都会复制一份克隆对象。

拷贝功能的实现：要实现克隆则需要implements Cloneable 接口，并重写Object 类中 clone()方法。->浅拷贝

深拷贝实现：

1、让每个引用类型属性内部都重写clone() 方法

2、要实现深复制，需要采用流的形式读入当前对象的二进制输入，再写出二进制数据对应的对象。

implements Serializable 接口，如果有某个属性不需要序列化，可以将其声明为 transient，即将其排除在克隆属性之外。

场景：序列化到磁盘，然后在反序列化到内存中。

应用 ：bean 原型模式

建造者模式(Builder)

定义：封装一个复杂对象构造过程，并允许按步骤构造。

解释：就是将复杂对象的创建过程拆分成多个简单对象的创建过程，并将这些简单对象组合起来构建出复杂对象。

应用：

  • StringBuilder：能够动态地构建字符串。

  • Stream API：将集合类转为stream流，通过一系列的中间操作和终止操作来生成最终结果。

  • Lombok的@Builder注解：一个注解就可以生成建造者模式的代码。

XXbulider对象 ,解决复杂对象创建。

和工厂模式区别：维度不同，工厂直接new() 关注类型，关注的是创建本身。

结构型(Structural)

  • 代理模式(Proxy)

  • 适配器模式(Adapter)

  • 桥接模式(Bridge)

  • 组合模式(Composite)

  • 装饰模式(Decorator)

  • 外观模式(Facade)

  • 享元模式(Flyweight)

搭积木（类或对象结合在一起形成一个更大的结构）。

代理模式（Proxy)

为其它对象提供一种代理，以控制对 这个对象的访问。

代理对象在客户端和目标对象之间起到中介的作用

如 : 租客通过中介找房东租房子 , 房东将房子托管给了中介 , 房东是目标对象 , 但是租赁行为是中介来执行的 , 中介是代理类 , 租客 就是 客户端 ; 中介 代理 房东 进行租赁行为 , 相当于 代理类对目标对象进行了增强 ;

客户端 通过 代理类 与 目标对象 进行交互 , 客户端 不直接接触 目标对象 ;

代理模式的应用场景：

如果已有的方法在使用的时候需要对原有的方法进行改进，此时有两种办法：

  1. 修改原有的方法来适应。这样违反了“对扩展开放，对修改关闭”的原则。

  2. 就是采用一个代理类调用原有的方法，且对产生的结果进行控制。这种方法就是代理模式。

使用代理模式，可以将功能划分的更加清晰，有助于后期维护！

public interface Sourceable {public void method();
}
​
public class Source implements Sourceable {@Overridepublic void method() {System.out.println("the original method!");}
}
​
public class Proxy implements Sourceable {private Source source;public Proxy(){super();this.source = new Source();}@Overridepublic void method() {before();source.method();atfer();}private void atfer() {System.out.println("after proxy!");}private void before() {System.out.println("before proxy!");}
}
#测试类public class ProxyTest {public static void main(String[] args) {Sourceable source = new Proxy();source.method();}}

输出：

before proxy! the original method! after proxy!

代理扩展：

静态代理 : 在代码中 , 使用指定的代理 ; 显示的定义了一个业务实现类代理 ; 在代理类中 , 对同名的业务方法进行包装 , 用户通过调用 代理类中 被包装过的业务逻辑方法 , 来调用 被包装对象 的业务方法 , 同时对目标对象的业务方法进行增强 ;

动态代理 : 由 JDK 提供 , 只能对 实现的接口的类 进行动态代理 , 不能代理具体的实现类 ; 通过 接口 中的 方法名 , 在 动态生成的 代理类 中 , 调用 业务实现类 的 同名方法 ;

JDK 动态代理 , 用到的代理类 , 是在程序调 用到代理对象时 , 由 Java 虚拟机创建 , Java 虚拟机 根据传入的 业务实现类对象 以及 方法名 , 动态地创建代理类 Class 文件 , 当该 Class 文件被字节码引擎执行 , 通过该代理类对象进行目标方法的调用 ;

动态代理无法代理类 , 只可以代理接口 ;

CGLib 代理 : 可以 针对类实现进行代理 ;

如果要 代理一个类 , CGLib 会生成一个被代理类的子类 , 通过 继承该类 并 覆盖其中的方法 ; 如果该类时 final 的 , 则无法被继承 , 如果类中的方法是 final 的 , 该方法无法被重写 ; 使用 CGLib 代理要特别注意 final 修饰符 ;

  1. 静态代理，代理类需要自己编写代码写成。

  2. 动态代理，代理类通过 Proxy.newInstance() 方法生成。

  3. JDK实现的代理中不管是静态代理还是动态代理，代理与被代理者都要实现两样接口，它们的实质是面向接口编程。

    CGLib可以不需要接口。

  4. 动态代理通过 Proxy 动态生成 proxy class，但是它也指定了一个 InvocationHandler 的实现类。

    应用场景：接口统一处理（日志、认证、参数的加解密）

    代理模式和装饰者模式 :

    装饰者模式 是为 目标对象 添加行为 ;

    代理模式 目的是进行 控制访问 , 代理模式 注重 通过设置 代理对象 的方式 , 增强目标对象 , 一般是 增强目标对象的某些行为 ;

    代理模式和适配器模式 :

    适配器模式 主要 改变 所考虑对象的接口 , ​ 代理模式 不能 改变 代理类的接口 , 原文链接：【设计模式】代理模式 ( 简介 | 适用场景 | 优缺点 | 代理扩展 | 相关设计模式 )_论述代理模式的应用场景与优点,并举例进行论证-CSDN博客

适配器（Adapter)

Adapter Pattern 将一个接口转换成客户希望的另一个接口；把不兼容接口变成兼容的。

将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。

把两个不兼容对象，通过适配器能够连接起来。

一个中文人，一个外国人，说话，通过一个翻译人;

主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。首先，我们来看看类的适配器模式，先看类图：

1、类的适配器模式

核心思想就是：有一个Source类，拥有一个方法，待适配，目标接口时Targetable，

通过Adapter类，将Source的功能扩展到Targetable里，

看代码：

public class Source {public void method1() {System.out.println("this is original method!");}
}
​
public interface Targetable {/* 与原类中的方法相同 */public void method1()/* 新类的方法 */public void method2();
}
public class Adapter extends Source implements Targetable {
​@Overridepublic void method2() {System.out.println("this is the targetable method!");}
}

Adapter类继承Source类，实现Targetable接口，下面是测试类：

public class AdapterTest {public static void main(String[] args) {Targetable target = new Adapter();target.method1();target.method2();}
}

输出：

this is original method! this is the targetable method!

这样Targetable接口的实现类就具有了Source类的功能。

2、对象的适配器模式

基本思路和类的适配器模式相同，只是将Adapter类作修改，这次不继承Source类，而是持有Source类的实例，以达到解决兼容性的问题。看图：

Adapter类的源码即可：

public class Wrapper implements Targetable {private Source source;public Wrapper(Source source){super();this.source = source;}
​@Overridepublic void method2() {System.out.println("this is the targetable method!");}
​@Overridepublic void method1() {source.method1();}
}

测试类：

public class AdapterTest {public static void main(String[] args) {Source source = new Source();Targetable target = new Wrapper(source);target.method1();target.method2();}
}

输出与第一种一样，只是适配的方法不同而已。

3、接口的适配器模式

有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，必须实现该接口的所有方法，这明显有时比较浪费，因为并不是所有的方法都是我们需要的，有时只需要某一些，此处为了解决这个问题，我们引入了接口的适配器模式，借助于一个抽象类，该抽象类实现了该接口，实现了所有的方法，而我们不和原始的接口打交道，只和该抽象类取得联系，所以我们写一个类，继承该抽象类，重写我们需要的方法就行。看一下类图：

这个很好理解，在实际开发中，我们也常会遇到这种接口中定义了太多的方法，以致于有时我们在一些实现类中并不是都需要。看代码：

public interface Sourceable {public void method1();public void method2();
}

抽象类Wrapper2：

public abstract class Wrapper2 implements Sourceable{public void method1(){}public void method2(){}
}
​
public class SourceSub1 extends Wrapper2 {public void method1(){System.out.println("the sourceable interface's first Sub1!");}
​
public class SourceSub2 extends Wrapper2 {public void method2(){System.out.println("the sourceable interface's second Sub2!");}
}
​
public class WrapperTest {public static void main(String[] args) {Sourceable source1 = new SourceSub1();Sourceable source2 = new SourceSub2();source1.method1();source1.method2();source2.method1();source2.method2();}
}

测试输出：

the sourceable interface's first Sub1! the sourceable interface's second Sub2!

达到了我们的效果！

讲了这么多，总结一下三种适配器模式的应用场景：

类的适配器模式：当希望将一个类转换成满足另一个新接口的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。

对象的适配器模式：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。

接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。

应用：springAop- beforeAdvice、AfterAdvice、ThrowsAdvice

Spring mvc中 Todo 看springmvc适配器

场景：

1、系统集成

当需要将新的外部系统或第三方库集成到现有系统中，且它们的接口不兼容时，适配器模式非常有用。例如，现有系统 A 通过接口oldInterface进行数据传输，新接入的系统 B 提供的是newInterface接口，这时可以创建一个适配器类，实现oldInterface，在内部调用newInterface，从而使系统 A 能够顺利和系统 B 通信。

2、旧接口升级

对旧接口进行升级后，为了让依赖旧接口的代码仍能正常工作，可以使用适配器模式。假设原来有一个接口OldService，它有一些方法供其他模块调用。现在对服务进行升级，产生了新接口NewService，可以创建一个适配器实现OldService，在内部调用NewService相关方法来适配旧的调用方式。

3、不同格式数据转换

在处理不同格式的数据时，如不同格式的文件（XML 和 JSON）之间的转换。如果有一个模块期望接收 XML 格式的数据输入，而现在有一个 JSON 格式的数据来源，就可以通过适配器将 JSON 数据转换为 XML 格式来满足模块的需求。

装饰（Decorator/Wrapper）

动态地给对象增加一些职责，即增加其额外的功能。

Wrapper 动态的为一个对象增强新功能(就增加功能来说，装饰模式相比生成子类更为灵活)

装饰器模式的应用场景：

  1. 需要扩展一个类的功能。

  2. 动态的为一个对象增加功能，而且还能动态撤销。（继承不能做到这一点，继承的功能是静态的，不能动态增删。）

缺点：产生过多相似的对象，不易排错！

装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口。装饰对象持有被装饰对象的实例，关系图如下：

Source类是被装饰类，Decorator类是一个装饰类，可以为Source类动态的添加一些功能，代码如下：

public interface Sourceable {public void method();
}
​
public class Source implements Sourceable {@Overridepublic void method() {System.out.println("the original method!");}
}
​
public class Decorator implements Sourceable {private Sourceable source;public Decorator(Sourceable source){super();this.source = source;}@Overridepublic void method() {System.out.println("before decorator!");source.method();System.out.println("after decorator!");}
}

public class DecoratorTest {public static void main(String[] args) {Sourceable source = new Source();Sourceable obj = new Decorator(source);obj.method();}
}

IO流包装、数据源包装

inputStream输入流的所有类的基类，

fileInputStream读取文件信息、

ByteArrayInputStream内存缓冲区、

BufferedInputStream缓冲

BufferedInputStream f = new BufferedInputStream(new FileInputStream (new File(“c:/test.txt”)));

场景：①有个类已经写好了，要扩展功能

比如现在有个上传文件处理的类，要增加检查文件大小必须符合一个范围，又不能改动上传文件处理，

就可以写个装饰器类，处理完了再交给代理的实际上传文件处理类。

待更新...


http://www.mrgr.cn/news/80729.html

相关文章：

  • 小程序快速实现大模型聊天机器人
  • Group FLUX - User Usage Survey Report
  • 前端面试汇总(不定时更新)
  • 3分钟读懂数据分析的流程是什么
  • 深入理解NPM：Node.js的包管理器
  • Halcon中derivate_gauss (Operator)算子原理及应用详解
  • harbor离线安装 配置https 全程记录
  • Flutter环境搭建
  • vue复习
  • zlmediakit搭建直播推流服务
  • ubuntu server 安装
  • vue2,vue3 中 v-for 和v-if的优先级
  • AI自我进化的新篇章：谷歌DeepMind推出苏格拉底式学习，语言游戏解锁无限潜能
  • 搭建分布式Spark集群
  • K8s中 statefulset 和deployment的区别
  • 音频开发中常见的知识体系
  • 大腾智能CAD：国产云原生三维设计新选择
  • K8s ConfigMap的基础功能介绍
  • 网络编程 02：IP 地址，IP 地址的作用、分类，通过 Java 实现 IP 地址的信息获取
  • 搭建分布式ZooKeeper集群
  • 贪心算法求解跳跃游戏
  • GEE+本地XGboot分类
  • Redis bitmaps 使用
  • MySQL中in和exists的使用场景
  • 牛客网 SQL36查找后排序
  • WPF+MVVM案例实战与特效（四十二）- 打造炫酷彩虹字控件,让你的应用闪耀起来