初探设计模式——装饰者模式 ，在I/O中的身影

初次学习，如有谬论请不吝斧正。

组合的威力是强大的，可以在运行时动态扩展而不改变原来的功能。
第四个设计原则：类应该对扩展开放，对修改关闭
应用这个原则通常会引入新的抽象层次，过多的引入会使代码复杂度增加。
装饰者模式：动态的将责任附加到对象身上

首先引入一个抽象层次，针对抽象类编程

public abstract class Beverage{
	String description ="Unknow";
	public String getDescription(){
		return description;
	}
	public abstract double cost();
}

装饰者和被装饰者都继承这个抽象类，也就实现了“类型匹配”，依靠这个超类 装饰者就能取代（包含）被装饰者，
行为来自被装饰者和组合它的装饰者们，这样 添加装饰者组件就可以添加行为

被装饰者

public class Espress extends Beverage{
	public Espresso(){
		description="Espresso";
	}
	public double cost(){
		return 1.9;
	}
}

装饰者抽象类（封装变化，面向超类型编程）

public abstract class CondimentDecorator extends Beverage{
	public abstract String getDescription();	//用来在描述装饰者信息时也描述组件，是个委托回溯的过程
}

写一个具体的装饰者组件

public class Mocha extends CondimentDecorator{
	Beverage beverage;
	public Mocha(Beverage beverage){
		this.beverage=beverage;
	}
	public String getDescription(){
		return beverage.getDescription()+"Mocha";
	}
	public double cost(){
		return 0.1+beverage.cost();
	}

}

测试代码
方法的调用权先一步步委托到被装饰者再不断回溯。

public class Starbuzz Coffee{
	public static void main(String[] args){
		Beverage beverage=new Espress();	//得到一个被装饰者
		beverage =new Mocha(beverage);		//组合一个Mocha装饰组件
		beverage =new Other(beverage);		//再组和到上一个类
		System.out.println(beverage.getDescription()
			+"$"+beverage.cost());
	}
}

• I/O包中的FilterputStream就是装饰者抽象类，通过继承它就可以扩展出许多装饰者组件。由于扩展方便，出现了很多API。
• 装饰者抽象类实例化组件会增加代码复杂度。
• 类型问题？？

。。。