Java代码安全设计-设计模式-装饰模式

最新推荐文章于 2024-07-29 14:22:26 发布
最新推荐文章于 2024-07-29 14:22:26 发布
阅读量199 收藏 1
点赞数 1
分类专栏： Java代码审计-设计模式 文章标签： java 安全 设计模式 装饰器模式 网络安全
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ayunlong/article/details/130298212
版权

Java设计模式-装饰模式(Decorate)

目录

  • 为什么要使用装饰模式
  • 什么是装饰模式
  • JavaSE装饰模式的应用
  • Struts2装饰模式的应用

1、装饰模式是为了解决类功能扩展，而不增加类与子类的耦合性。

2、不要让自己停留在审计OWASP TOP10漏洞的阶段，赶紧突破。

一、为什么要使用装饰模式

1.1 使用原生的HttpServlet，实现对所有HTTP请求的参数过滤如何做？

我们知道Servlet可以在doGet、doPost中方法中接收HTTP的参数，如果要过滤参数，那么肯定要在doGet与doPost中处理，在每个doGet与doPost都做修改，会带来哪些问题？

  1. 重复代码过多
  2. 代码扩展性差

如果要修改需求，比如增加过滤的特殊字符，或者修改过滤的逻辑，都会引起所有过滤代码的修改，所以要用装饰模式解决问题（要彻底解决问题需要装饰模式+Filter，本文不体现Filter）。

1.2 实现过滤HTTP参数的功能

该项目复用【JSPServlet】项目代码，代码如下（只展示了核心代码）

SafeLogin.java ：登录业务

MyHttpServletRequest：扩展的HttpServletRequestWrapper装饰类

web.xml ：定义新增的SafeLogin类

public class SafeLogin extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 使用自定义的HttpServletRequest的装饰类，里面定义了参数的过滤方法
        MyHttpServletRequest safeRequest = new MyHttpServletRequest(request);
        // 这里调用的getParameter，是MyHttpServletRequest的getParameter方法，定义了过滤参数的方法
        String userName = safeRequest.getParameter("username");
        String password = safeRequest.getParameter("password");

        System.out.println("过滤后 username：" + userName);
        System.out.println("过滤后 password：" + password);
    }
}

public class MyHttpServletRequest extends HttpServletRequestWrapper {
    /**
     * Constructs a request object wrapping the given request.
     *
     * @param request
     * @throws IllegalArgumentException if the request is null
     */
    public MyHttpServletRequest(HttpServletRequest request) {
        super(request);
    }

    @Override
    public String getParameter(String name) {
        // 调用父类的getParameter方法，也就是原生的HttpServletRequest
        String value = super.getParameter(name);
        System.out.println("过滤前 " + name + "：" + value);
        value = value.replace("'","");
        return value;
    }
}

<servlet>
    <servlet-name>safeLogin</servlet-name>
    <servlet-class>org.example.SafeLogin</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>safeLogin</servlet-name>
    <url-pattern>/safeLogin</url-pattern>
</servlet-mapping>

可以发现在SafeLogin中，使用了自定义的MyHttpServletRequest装饰类，该类继承了HttpServletRequestWrapper，所以，想要扩展HttpServletRequest，就需要继承HttpServletRequestWrapper类，有这样的好处：

  1. 对原始类HttpServletRequest没有任何侵入性，不必对原始类做任何修改
  2. 通过继承装饰类实现对原始类的装饰，扩展性好，也可以扩展多个装饰类，例如：过滤SQL字符、过滤XSS特殊字符等

对于初学者会有这样的疑问：

  1. 什么是装饰模式
  2. 为什么要继承HttpServletRequestWrapper，而不是HttpServletRequest
  3. HttpServletRequest与HttpServletRequestWrapper是什么关系

对于前两个问题我们在本文的后面小结解答，先看第三个问题

下面是关于HttpServletRequest的类UML图

image-20230201112535142

根据装饰模式的特点，将HttpServletRequest的装饰模式分解如下（这是装饰模式的关键点，现在看不明白没关系，下面文章会详细讲解）

  1. 抽象组件(Component) ：定义装饰方法的规范 – ServletRequest类
  2. 被装饰者(ConcreteComponent) ：Component的具体实现，也就是我们要装饰的具体对象 – HttpServletRequest接口
  3. 装饰者组件(Decorator) ：持有组件(Component)对象的实例引用，该类的职责就是为了装饰具体组件对象，定义的规范 – ServletRequestWrapper类
  4. 具体装饰(ConcreteDecorator) ：负责给构件对象装饰附加的功能。-- HttpServletRequestWrapper、MyServletRequest类

了解完后，HttpServletRequest与HttpServletRequestWrapper是什么关系的问题迎刃而解，HttpServletRequestWrapper是HttpServletRequest的装饰类，通过装饰类扩展HttpServletRequest的功能。

为什么要继承HttpServletRequestWrapper，而不是HttpServletRequest？

一定要继承HttpServletRequestWrapper吗？其实不是，通过类的UML图可以看出，继承HttpServletRequestWrapper和继承ServletRequestWrapper是一样的，两者都是HttpServletRequest的装饰类。

最后一个问题，什么是装饰模式？什么情况下使用装饰模式？

  1. 你不希望修改原类，但想动态扩展原类功能，也可动态撤销
  2. 使用继承扩展对象行为不可行，继承是扩展对象功能最直接的方式，但代码耦合太强，而且最后不用继承层次太深
  3. 被final限制的类

二、什么是装饰模式

首先说一个开发场景

1月15日：产品经理找到你说：开发一个饮料售卖平台，前期只卖水

2月15日：产品经理又找你，说想卖可乐、芬达

3月1日：又找你，想可乐加冰

4月1日：又找你，想可乐加柠檬

可以看出产品的需求是多变的，各类设计模式的出现，解决的就是产品需求多变的问题而导致的代码重用性、耦合性、可维护性问题

比如第一次需求，我们只需要声明一个Water类就能完成需求

/**
 * 可乐
 */
public class Water {
    // 可乐的价格
    final int COLA_PRICE = 5;
    public int price() {
        System.out.println("可乐需要 " + COLA_PRICE + " 元");
        return COLA_PRICE;
    }
}

而后面的可乐、芬达、加冰、加柠檬的需求，可以在定义4个类，分别满足需求，但需求是多变的，假如某天可乐中要加100种调料，难道要写100个类？每个类中都写price方法？如果客户想添加3中调料呢？那可能会想那在类中定义3个调料的价格计算就行了，但你要知道，用户加的调料是不同的，难道要写100个调料的排列组合？这简直不可能，因为会造成2个问题：

  1. 每个类都有计算可乐+调料的方法，造成重复代码多
  2. 如果增加/删除一种调料、修改调料价格，那么所有涉及到的类都要改

所以就要想办法解决上面的问题，如何更好的给可乐增加调料？

直接看代码吧，代码结构如下

image-20230116162613427

Water.java

package org.decorate.drinks;

/**
 * 最终要装饰的类，装饰为不同的饮料
 */
public interface Water {
    /**
     * 饮料的价格
     * @return
     */
    public int price();
}

drinks.Cola.java

package org.decorate.drinks.drinks;

import org.decorate.drinks.Water;

/**
 * 可乐
 */
public class Cola implements Water {
    // 可乐的价格
    final int COLA_PRICE = 5;
    public int price() {
        System.out.println("可乐需要 " + COLA_PRICE + " 元");
        return COLA_PRICE;
    }
}

drinks.Fanta.java

package org.decorate.drinks.drinks;

import org.decorate.drinks.Water;

/**
 * 芬达饮料
 */
public class Fanta implements Water {
    // 芬达的价格
    final int FANTA_PRICE = 3;
    public int price() {
        System.out.println("芬达需要 " + FANTA_PRICE + " 元");
        return FANTA_PRICE;
    }
}

decorate.LceDecorate.java

package org.decorate.drinks.decorate;

import org.decorate.drinks.Water;
/**
 * 加冰
 */
public class IceDecorate implements Water {

    private Water water = null;
    private int ICE_PRICE = 1;

    public IceDecorate(Water water) {
        this.water = water;
    }

    public int price() {
        // 水的价格 + 冰的价格
        System.out.println("加冰需要 " + ICE_PRICE + " 元");
        return this.water.price() + ICE_PRICE;
    }
}

decorate.LemonDecorate.java

package org.decorate.drinks.decorate;

import org.decorate.drinks.Water;
/**
 * 加柠檬
 */
public class LemonDecorate implements Water {
    private Water water = null;
    private int LEMON_PRICE = 2;

    public LemonDecorate(Water water) {
        this.water = water;
    }

    public int price() {
        System.out.println("加柠檬需要 " + LEMON_PRICE + " 元");
        // 水的价格 + 柠檬的价格
        return this.water.price() + LEMON_PRICE;
    }
}

最终如何调用

package org.decorate.drinks;

import org.decorate.drinks.decorate.IceDecorate;
import org.decorate.drinks.decorate.LemonDecorate;
import org.decorate.drinks.drinks.Cola;

public class Customer {
    public static void main(String[] args) {
        // 客户要可乐加冰加柠檬
        Water water = new Cola();
        water = new IceDecorate(water);
        water = new LemonDecorate(water);
        int price = water.price();
        System.out.println("顾客需要支付 " + price + "元");

    }
}

在Customer类中选择饮料时，可以发现无论我如何选择调料，都不需要改其它类，只需要修改调用的代码即可，非常方便，哪怕后来多了其它饮料的种类，想加冰加柠檬都是可以直接调用的，这就是装饰模式的好处

我们抽象下装饰模式的基本特性

  1. 抽象构建Component（接口or抽象类 – Water）
  2. 抽象构建的实现类（主要是对这个类进行装饰 – Cola、Fanta）
  3. 具体的装饰类（你要装饰的代码类 – IceDecorate、LemonDecorate ，属性里必然有一个private变量指向Component抽象构(Water)）。

类的关系图如下

image-20230421165615627

也可以将装饰类抽象为抽象方法，形成如下图

image-20230421165553600

再次抽象下装饰模式的基本特性

  1. 抽象组件(Component) ：定义装饰方法的规范 – Water类
  2. 被装饰者(ConcreteComponent) ：Component的具体实现，也就是我们要装饰的具体对象 – Cola、Fanta类
  3. 装饰者组件(Decorator) ：持有组件(Component)对象的实例引用，该类的职责就是为了装饰具体组件对象，定义的规范 – Decorator类
  4. 具体装饰(ConcreteDecorator) ：负责给构件对象装饰附加的功能。-- IceDecorator、lemonDecorator类

看下具体代码，其中Water.java、Cola.java、Fantta.java类与前面一样，主要看下IceDecorator、lemonDecorator、Decorator类

Water.java

package org.decorate.drinks;

/**
 * 最终要装饰的类，装饰为不同的饮料
 */
public interface Water {
    /**
     * 饮料的价格
     * @return
     */
    public int price();
}

drinks.Cola.java

package org.decorate.drinks.drinks;

import org.decorate.drinks.Water;

/**
 * 可乐
 */
public class Cola implements Water {
    // 可乐的价格
    final int COLA_PRICE = 5;
    public int price() {
        System.out.println("可乐需要 " + COLA_PRICE + " 元");
        return COLA_PRICE;
    }
}

drinks.Fanta.java

package org.decorate.drinks.drinks;

import org.decorate.drinks.Water;

/**
 * 芬达饮料
 */
public class Fanta implements Water {
    // 芬达的价格
    final int FANTA_PRICE = 3;
    public int price() {
        System.out.println("芬达需要 " + FANTA_PRICE + " 元");
        return FANTA_PRICE;
    }
}

Decorator.java

package org.decorate.drinks2.decorate;

import org.decorate.drinks2.Water;

/**
 * 装饰抽象类
 */
public abstract class Decorate implements Water {
    private Water water = null;
    public Decorate(Water water){
        this.water = water;
    }
    public int price() {
        return this.water.price();
    }
}

decorate.IceDecorator.java

package org.decorate.drinks2.decorate;

import org.decorate.drinks2.Water;

/**
 * 加冰
 */
public class IceDecorate extends Decorate{
    final private int  ICE_PRICE = 1;
    public IceDecorate(Water water) {
        super(water);
    }

    public int price() {
        // 水的价格 + 冰的价格
        System.out.println("加冰需要 " + ICE_PRICE + " 元");
        return super.price() + ICE_PRICE;
    }
}

decorate.LemonDecorator.java

package org.decorate.drinks2.decorate;

import org.decorate.drinks2.Water;

/**
 * 加柠檬
 */
public class LemonDecorate extends Decorate{
    final private int LEMON_PRICE = 1;
    public LemonDecorate(Water water) {
        super(water);
    }

    public int price() {
        // 水的价格 + 柠檬的价格
        System.out.println("加柠檬需要 " + LEMON_PRICE + " 元");
        return super.price() + LEMON_PRICE;
    }
}

对比下两种实现方式，可以发现后面一种的类关系更加清晰，而且每个具体的装饰类中都减少了Water类的引用，减少了代码量，也减少了对象的生成。

image-20230116174437409

三、JavaSE装饰模式的应用

JavaSE中对装饰模式的应用，最典型的就是IO流，例如下面代码

static final String FILE = "test.log";
Reader reader = new InputStreamReader(new FileInputStream(FILE));

在大学中学习Java时，只知道这句话是创建了InputStreamReader对象，构造方法传递了FileInputStream对象，这样就可以读取一个文件，但并不明白为什么这么做，也没有调试过JDK的源码，并不明白什么是设计模式，只知道如何去用。

到现在开始分析Java代码安全时，分析的越深入，发现很多设计模式如果不明白，就会限制自己。

这里想到了《凤凰项目一个IT运维的传奇故事》的一句话

创建约束理论的艾利高德拉特告诉我们，在瓶颈之外的任何地方做出的改进都是假象。

所以必须要解决瓶颈问题，也就是对设计模式的盲区，要不然自己会永远停留在审计OWASP TOP10的阶段，那将是职业生涯的灾难。

从前面的读文件代码，就是非常典型的装饰模式，首先先看三种不同的对文件读取的方式

package org.decorate;

import java.io.*;

public class JavaSEDecorate {
    static final String FILE = "test.log";
    public static void main(String[] args) throws IOException {
        test1();
    }
    public static void test1() throws IOException {
        BufferedReader in = new BufferedReader(new FileReader(FILE));
        String str;
        while ((str = in.readLine()) != null) {
            System.out.println(str);
        }
        in.close();
    }

    public static void test2() throws IOException{
        InputStream in = new FileInputStream(FILE);
        int tempbyte;
        while ((tempbyte = in.read()) != -1) {
            System.out.write(tempbyte);
        }
        in.close();
    }

    public static void test3() throws IOException {
        char[] tempchars = new char[3];
        int charread = 0;
        Reader reader = new InputStreamReader(new FileInputStream(FILE));
        // 读入多个字符到字符数组中，charread为一次读取字符数
        while ((charread = reader.read(tempchars)) != -1) {
            System.out.print(tempchars);
        }
    }
}

以上面的三种方式的一个为例

BufferedReader in = new BufferedReader(new FileReader(FILE));

回忆下前面关于装饰模式的四个关键点，但这个只用到了三个关键点的模式，对应到BufferedReader类中

  1. 抽象组件(Component) ：定义装饰方法的规范（FileReader与BufferedReader的共同父类） – Reader类
  2. 被装饰者(ConcreteComponent) ：Component的具体实现，也就是我们要装饰的具体对象 – FileReader类
  3. 具体装饰(ConcreteDecorator) ：负责给构件对象装饰附加的功能，持有组件(Component)对象的实例引用Reader。-- BufferedReader类

可以看到非常符合装饰模式的应用

FileReader封装StreamDecoder类封装FileInputStream类，最终BufferedReader.readLine方法，调用的是StreamDecoder.read()方法，只不过BufferedReader.readLine方法进行了字符串的封装处理

image-20230116155316235

为什么要这么嵌套呢？我们读文件时，比较自然的思路是逐行阅读，这是比较贴近人类的阅读方式，OK，我们看下FileReader类中有哪些方法，点一下下图标红按钮，可以看到父类继承的方法

image-20230116152243207

可以看到只有read方法，并没有我们想的readLine方法，在看下BufferedReader类的方法

image-20230116152448064

可以看到BufferedReader类中是有readLine方法，在FileReader类的基础上装饰了readLine方法

附一张IO流的继承关系图

img

通过上图可以看到IO流有字节流与字符流两类，而如何将字节转为字符流？答案是InputStreamReader和OutputStreamWriter，其中用都是装饰模式的设计方法

BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream(new File("text.txt"))));

image-20230116154032422

四、Struts2装饰模式的应用

  1. StrutsRequestWrapper
  2. OgnlContext
  3. OgnlTypeConverterWrapper
  4. OgnlNullhandlerWrapper

首先StrutsRequestWrapper扩展的是HttpServletRequestWrapper类，和我们前面自定义的MyServletRequest是相同道理，不在赘述

OgnlContext类代码如下，扩展的是Map类，内部持有一个Map对象

public class OgnlContext extends Object implements Map
{    
    private static Map RESERVED_KEYS = new HashMap(11);        
    private Map _values = new HashMap(23);
    private int _localReferenceCounter = 0;
    private Map _localReferenceMap = null;
    public OgnlContext(Map values)
    {
        super();
        this._values = values;
    }    
    public Map getValues()
    {
        return _values;
    }
    public void setValues(Map value) {
         for(Iterator it = value.keySet().iterator(); t.hasNext();) { 
         Object k = it.next();
          _values.put(k, value.get(k)); 
          } 
     } 
      //省略了代码...
}

类的关系图如下

image-20230201161740190

  1. 抽象组件(Component) ：定义装饰方法的规范（FileReader与BufferedReader的共同父类） – Object类
  2. 被装饰者(ConcreteComponent) ：Component的具体实现，也就是我们要装饰的具体对象 – Map接口
  3. 具体装饰(ConcreteDecorator) ：负责给构件对象装饰附加的功能，持有组件(Component)对象的实例引用Map。-- OgnlContext类

OgnlTypeConverterWrapper类的解析如下

  1. 抽象组件(Component) ：TypeConverter接口
  2. 被装饰者(ConcreteComponent) ：DefaultTypeConverter类
  3. 具体装饰(ConcreteDecorator) ：OgnlTypeConverterWrapper类、XWorkConverter（Struts中的装饰类）
public interface TypeConverter
{
    public Object convertValue(Map context, Object target, Member member, String propertyName, Object value, Class toType);
}

public class OgnlTypeConverterWrapper implements ognl.TypeConverter {  //接口实现是ognl接口
 
    private TypeConverter typeConverter;//实际传参是Struts自己的接口内
    
    public OgnlTypeConverterWrapper(TypeConverter conv) {
        if (conv == null) {
            throw new IllegalArgumentException("Wrapped type converter cannot be null");
        }
        this.typeConverter = conv;
    }
    
    public Object convertValue(Map context, Object target, Member member,    //他们有完全一样的方法
            String propertyName, Object value, Class toType) {
        return typeConverter.convertValue(context, target, member, propertyName, value, toType);
    }
    
    public TypeConverter getTarget() {
        return typeConverter;
    }
}

public class DefaultTypeConverter implements TypeConverter {
 
    public Object convertValue(Map<String, Object> context, Object target, Member member,
            String propertyName, Object value, Class toType) {
        return convertValue(context, value, toType);
    }
    
    public TypeConverter getTypeConverter( Map<String, Object> context )
    {
        Object obj = context.get(TypeConverter.TYPE_CONVERTER_CONTEXT_KEY);
        if (obj instanceof TypeConverter) {
            return (TypeConverter) obj;
            
        // for backwards-compatibility
        } else if (obj instanceof ognl.TypeConverter) {
            return new XWorkTypeConverterWrapper((ognl.TypeConverter) obj);
        }
        return null; 
    }
 
    public Object convertValue(Object value, Class toType) {
        Object result = null;
 
        if (value != null) {
            /* If array -> array then convert components of array individually */
            if (value.getClass().isArray() && toType.isArray()) {
                Class componentType = toType.getComponentType();
........省略代码

public class XWorkConverter extends DefaultTypeConverter {
 
    protected HashMap<Class, Map<String, Object>> mappings = new HashMap<Class, Map<String, Object>>(); // action
    protected HashSet<Class> noMapping = new HashSet<Class>(); // action
    protected HashMap<String, TypeConverter> defaultMappings = new HashMap<String, TypeConverter>();  // non-action (eg. returned value)
    protected HashSet<String> unknownMappings = new HashSet<String>();     // non-action (eg. returned value)
 		
    // 要装饰的对象，持有组件(Component)对象的实例引用-满足要求
    private TypeConverter defaultTypeConverter;
    private ObjectFactory objectFactory;
    private FileManager fileManager;
    private boolean reloadingConfigs;
 
    protected XWorkConverter() {
    }
 
    @Inject
    public void setObjectFactory(ObjectFactory factory) {
        this.objectFactory = factory;
        // note: this file is deprecated
        loadConversionProperties("xwork-default-conversion.properties");
 
        loadConversionProperties("xwork-conversion.properties");
    }
 
    @Inject  //注入方法
    public void setDefaultTypeConverter(XWorkBasicConverter conv) {
        this.defaultTypeConverter = conv;
    }
 
    //省略许多方法和属性...
}

OgnlNullhandlerWrapper类的解析如下

  1. 抽象组件(Component) ：NullHandler接口
  2. 被装饰者(ConcreteComponent) ：ObjectNullHandler类
  3. 具体装饰(ConcreteDecorator) ：OgnlNullHandlerWrapper类
public interface NullHandler
{
    public Object nullMethodResult(Map context, Object target, String methodName, Object[] args);
 
    public Object nullPropertyValue(Map context, Object target, Object property);
}

public class ObjectNullHandler implements NullHandler
{
    /* NullHandler interface */
    public Object nullMethodResult(Map context, Object target, String methodName, Object[] args)
    {
        return null;
    }
 
    public Object nullPropertyValue(Map context, Object target, Object property)
    {
        return null;
    }
}

public class OgnlNullHandlerWrapper implements ognl.NullHandler {
 
    // 持有的被装饰的对象
    private NullHandler wrapped;
    
    public OgnlNullHandlerWrapper(NullHandler target) {
        this.wrapped = target;
    }
    
    public Object nullMethodResult(Map context, Object target,
            String methodName, Object[] args) {
        return wrapped.nullMethodResult(context, target, methodName, args);
    }
 
    public Object nullPropertyValue(Map context, Object target, Object property) {
        return wrapped.nullPropertyValue(context, target, property);
    }
}
MarginSelf
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Java设计模式 ---- 装饰模式
qq_48651377的博客
05-12 3941
一、什么是装饰模式？        装饰模式是一种用于替代继承的技术，它通过一种无须定义子类的方式给对象动态增加职责，使用对象之间的关联关系取代类之间的继承关系。 定义：动态地给一个对象增加一些额外的职责。就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案。 二、装饰模式结构与实现 1、结构 （1）Component（抽象构件）： 具体构件和抽象装饰类的共同父类。 （2）ConcreteComponent（具体构件）
Java常见设计模式总结
热门推荐
张维鹏的博客
09-18 18万+
设计模式是一套经过反复使用的代码设计经验，目的是为了重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式于己于人于系统都是多赢的，它使得代码编写真正工程化，它是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。总体来说，设计模式分为三大类：5种创建型模式、7种结构型模式、11种行为型模式
构建一个java项目，对于安全方面，需要哪些业务模块
zbh1957282580的博客
06-03 897
构建一个Java项目时，安全方面需要考虑多个业务模块，以确保系统的安全性和数据的完整性。
Java中23种设计模式
呜呜老司机的博客家园
10-10 7万+
Java中23种设计模式，包括简单介绍，适用场景以及优缺点等
Java设计模式-装饰者模式
m0_62946761的博客
12-29 2795
Java设计模式之一的装饰者模式，在装饰类继承+组合被装饰类。结合例子可以更加清晰的理解装饰者模式。
Java设计模式--装饰者模式
Boogie
05-21 3576
在学习Mybatis二级缓存时，了解到sqlsessin对象会使用到一个Executor和相应的CachingExecutor的装饰者模式。所以就来具体了解一下。 Mybatis二级缓存详解–》https://blog.csdn.net/luanlouis/article/details/41408341。 强烈推荐！！！ 接下来具体讨论装饰者模式： 装饰者模式定义： 动态地将责任...
java设计模式--装饰模式
ChanYee的博客
07-06 664
装饰模式： 动态的将责任附加给了对象，使对象易于横向和总想扩展，提供了比继承更有弹性的替代方案。我们来看一下代码片段 创建一个要唱歌的人/** * @author Lichenyi * @date 2017-7-6 */ public interface Human { public void sing(); }//把这个人包装成为一个歌手/** * @author Lichen
Java设计模式——装饰器模式
tang_seven的博客
02-10 3980
简要叙述java设计模式装饰器模式，并进行代码的示例
Java设计模式 ---（一）
As_Yua的博客
07-09 1954
工厂模式将目的将创建对象的具体过程屏蔽隔离起来，从而达到更高的灵活性，工厂模式可以分为三类：简单工厂模式（Simple Factory）工厂方法模式（Factory Method）抽象工厂模式（Abstract Factory）我们在了解工厂模式时，先从现实生活说起:（1）在没有工厂的时代，如果客户需要一款宝马车，那么就需要客户去创建一款宝马车，然后拿来用。（2）简单工厂模式：后来出现了工厂，用户不再需要去创建宝马车，由工厂进行创建，想要什么车，直接通过工厂创建就可以了。
设计模式-装饰者模式在Java中的使用示例
BADAO_LIUMANG_QIZHI的博客
11-02 1270
是指在不改变原有对象的基础上，将功能附加到对象上，提供了比继承更有弹性的方案。适用场景：1、扩展一个类的功能或给一个类添加职责。2、动态给一个对象添加功能，这些功能可以再动态地撤销。3、生活中的应用比如给房子装修、给煎饼果子加肠、给蛋糕加巧克力。注：博客：关注公众号霸道的程序猿获取编程相关电子书、教程推送与免费下载。
java高频面试题-设计模式
q66562636的博客
06-07 3864
1 你所知道的设计模式有哪些？Java 中一般认为有 23 种设计模式，我们不需要所有的都会，但是其中常用的几种设计模式应该去掌握。下面列出了所有的设计模式。需要掌握的设计模式我单独列出来了，当然能掌握的越多越好。总体来说设计模式分为三大类：创建型模式，共5种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共7种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。行为型模式，共11种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘
java常用设计模式-装饰器模式
08-26
Java 设计模式 - 装饰器模式 装饰器模式（Decorator Pattern）是一种结构性设计模式，它允许您在不影响同一类的其他对象的行为的情况下，静态或动态地向单个对象添加行为。该模式非常有用，当您想要在运行时添加或...
Java设计模式-图解-附代码.doc
09-19
本文件“Java设计模式-图解-附代码.doc”主要探讨了Java语言中的设计模式，分为创建型、结构型和行为型三大类。下面将对这些模式进行详细解释。 1. **创建型模式**： - **工厂方法**：提供一个接口用于创建对象，...
设计模式--装饰者模式java例子
02-06
装饰者模式是软件设计模式中的一种结构型模式，它的主要目的是动态地给对象添加新的功能，而无需修改原有代码。在Java中，装饰者模式通常通过继承和组合来实现，它提供了一种比继承更灵活的方式来扩展对象的功能。...
使用hutool工具判断字符串是否全部是字母(包括大小写)，java判断字符串是否全部是字母(包括大小写)
最新发布
qq_43700885的博客
07-29 251
1.导入hutool的maven依赖。2.复制一下代码执行。
golang 接口
m0_70982551的博客
07-24 1009
接口定义了一组方法，这些方法没有具体的实现。接口类型的变量可以存储任何实现了这些方法的类型的值。// 更多方法...在Go语言中，接口值是指存储了实现某个接口的具体类型值的变量。接口值由两部分组成：1.动态类型：这是接口值当前存储的实际类型。2.动态值：这是实际存储的值，该值必须实现了接口中定义的所有方法。
java判断邮箱地址是否正确，使用hutool工具判断邮箱地址是否正确
qq_43700885的博客
07-29 96
1.导入hutool的maven依赖。2.直接复制一下代码运行。
Swagger使用Map接受参数时，页面如何显示具体参数及说
a1058926697的博客
07-26 545
后端使用Map接受参数，要求在swagger页面上显示具体的参数名称、类型及说明。当Map接受参数数量少时，可以使用Swagger自带的注解。自定义注解 @ApiGlobalModel。编写处理注解对应的插件。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

MarginSelf

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值