设计模式学习笔记装饰器模式和IO流

红太狼 2021-01-26 04:41 569阅读 0赞

# 怎么理解装饰器模式 #

*  装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。
 *  这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
 *  其实我们可以这样理解装饰器模式， 就拿自己举例子，你把自己裸体的样子，想象成被装饰的对象。你的鞋子，你的寸衣，你的外套，你的手表，你的帽子 等等，都是你的装饰物，你和这些装饰物，是装饰和被装饰的关系

# 举个简单例子 #

首先，我们发现，不管是裸体的人，还是你的鞋子、帽子，都有展示的功能，我们称之为show 方法。

我们定义一个接口，它具有展示的功能，也就是show()

public interface AbstractPerson {
     
    	//具有展示的功能
    	void show() ;
    }

定义一个裸体的自己了，Me 类

public class Me implements AbstractPerson {
     
    	@Override
    	public void show() {
    		System.out.println( "什么都没穿，我展示的是裸体");
    	}
     
    }

下面该定义，鞋子，帽子，手表等 装饰物，等等先别急，我们应该先定义一个鞋子，帽子，手表的抽象父类 AbstractClothes

public abstract class AbstractClothes implements AbstractPerson {
     
    	AbstractPerson abstractPerson ;
     
    	public AbstractClothes( AbstractPerson abstractPerson ){
    		this.abstractPerson = abstractPerson ;
    	}
     
    	@Override
    	public void show() {
    		abstractPerson.show();
    	}
     
    }

下面开始定义，帽子装饰物  Hat 类， 继承 AbstractClothes 类

public class Hat extends AbstractClothes {
     
    	public Hat(AbstractPerson abstractPerson) {
    		super(abstractPerson);
    	}
    	
    	@Override
    	public void show() {
    		super.show();
    	    say();
    	}
    	
    	public void say(){
    		System.out.println( "我展示一个帽子");
    	}
     
    }

定义鞋子装饰类 Shoes ,   继承 AbstractClothes 类

public class Shoes extends AbstractClothes {
     
    	public Shoes(AbstractPerson abstractPerson) {
    		super(abstractPerson);
    	}
    	
    	@Override
    	public void show() {
    		super.show();
    	    say();
    	}
    	
    	public void say(){
    		System.out.println( "我展示一双鞋子");
    	}
    }

test

public class Test {
     
    	public static void main(String[] args) {
     
    		//创建被装饰者
    		Me me = new Me() ;
     
    		//裸体的人被装饰了帽子 ，具有了展示帽子的能力
    		Hat hat = new Hat( me ) ;
     
    		// 带了帽子的人被装饰了鞋子，具有了展示鞋子的本领
    		Shoes shoes = new Shoes( hat ) ;
     
    		shoes.show();
    	}
    }

•什么都没穿，我展示的是裸体

•我展示一个帽子

•我展示一双鞋子

# UML类图 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70][]

*  Component抽象构件角色：真实对象和装饰对象有相同的接口。这样，客户端对象就能够以与真实对象相同的方式同装饰对象交互。
 *  ConcreteCompoent具体构建角色(真实对象)：定义一个将要接收附加责任的类。
 *  Decorator装饰角色：持有一个抽象构件的引用。装饰对象接受所有客户端的请求，并把这些请求转发给真实的对象。这样，就能在真实对象调用前后增加新的功能。
 *  ConcreteDecorate具体装饰角色：负责给构件对象增加新的功能。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70 1][]

*  Component抽象构件角色：io流中的InputStream,OutputStream,Reader,Writer
 *  ConcreteComponent具体构件角色：io流中的FileInputStream,FileOutputStream
 *  Decorate装饰角色：持有抽象构件的引用，FilterInputStream,FilterOutputStream
 *  ConcreteDecorate具体装饰角色：负责给构件对象添加新的责任，BufferedInputStream,BufferedOutputStream等

BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(new FileInputStream(path), "utf-8"));

# 装饰器模式的优点和缺点 #

**优点** ：扩展对象功能，比继承灵活，不会导致类个数急剧增加。可以对一个对象进行多次装饰，创造出不同行为的组合，得到功能更加强大的对象。具体构 件 类和具体装饰类可以独立变化，用户可以根据需要自己增加新的 具体构件子类和具体装饰子类。

**缺点**：产生很多小对象。大量小的对象占据内存，一定程度上影响性能。装饰模式易出错，调试排查比较麻烦。

# 场景 #

如果没有装饰器模式，还是我们上面的例子，我们就要生成穿鞋子的人的类，带帽子的人的类，同时穿鞋子和戴帽子的人的类。。。假设有4种装饰物和被装饰对象就有15种组合，如果类更多呢，就会使得类爆炸，这时候装饰器模式的优点就体现出来了，需要一个接口，一个个抽象类和5个实现类。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70]: /images/1611636226393.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70 1]: /images/1611636213965.png