设计模式 之 装饰器模式

设计模式 之 装饰器模式

我们都知道 ，设计模式都是前人在实际应用中，总结经验形成的一套模式。
今天要分享的呢，是装饰器模式，那么，它适用什么应用场景呢？

举个例子，比如日常女生出门穿衣化妆的过程，当然这里面涉及形象学，美学，艺术学…等等学科，很是复杂。但为了简单，我们就把它简化穿衣。 转换成编程语言，大概就是new Girl.调取穿衣的方法，然后就结束了。 呵呵，~ 果然我没有女朋友，大概也就是想的太simple了。

即便我想简化girl的动作，装份只考虑简单成穿衣一个动作，但它今天怎么装扮，确有成千上万个方案（就是方法），那么，如果把这些个方法，放在一个类中，会不会感觉有点不太好比如 ，把内裤和各种衣服叠放在一起，是不是不符合精致女孩的人设呢（当然，你可以）。
而装饰器模式，会成为作为一个精致girl的最佳闺中内务方案 。且看分析 。

标准框架

女生装份框架

//组件接口
public interface Component {

    	    public void method();
    	}

//组件实现类  
	
	public class ConcretComponent implements Component {

	    public void method() {
	        
	        System.out.println("我是组件实现类的重写方法");
	    }
	}  

	//装饰抽象类 
	
	public abstract Decorator implements Component {

	    public Component component;
	    
	    public Decorator(Component component) {
	        
	        this.component = component;
	    }
	    
	    public void method() {
	        
	        this.component.method();
	    }
	}  

	//具体装饰类  
	
	public class ConcreteDecorator extends Decorator {
        //通过父类的引用属性，构造出子类ConcreteDecorator对象
	    public ConcreteDecorator(Component component) {

	        super(component);
	    }

	    public void method() {
	        
	        System.out.println("..befor...");
	        this.component.method();
	        System.out.println("..after...");
	        
	    }
	}    

调用

   //使用装饰器
　　Component component = new ConcreteDecorator(new      ConcretComponent());
　　component.method();

　　//console：
　　    ...befor...
	    我是组件实现类的重写方法
	    ..after...

装饰器的好处：

• 装饰器可以理解为方法的增加 如ConcretComponent类，被ConcreteDecorator装饰后，使的它不光输出了原的的信息，同时也输出了 …befor… 和.after…
• 装饰器可以使业务功能更清晰，同时可以使代码解耦。 还以女生装份为例，女生出门会做3件事 1.上18层粉底，遮瑕 2.选择装扮风格 3…穿15公分的高根鞋(其实粉真没有18层，原谅我)，第1件事和第3件事都是固定的，只有第2件事是根据心情来选择，那么把2件事单独拿出来，分列成很多个装扮方案（方法），每次根据心情调用，是不是很方便，而对于第1件和第3件事，既然是固定模式，干脆把它放在装饰器中，只需要写一次代码，（如果放在每个装扮方案里，会重复N遍）。

看到这里，你可能还有疑问，为了实现方法的复用或增加，使用继承不就可以解决了，使用这么绕的装饰器模式何必呢。。。 其实也对，我认为如果装饰器的出现其实是做为继承之外的另一种方法重写的实现，但同时，装饰器模式有比继承没有的好处，（比如，上面女生装扮的例子，第1件事和第3件事是每天装扮的固定动作，而想要完成装扮的全过程只需要根据实际情况，调用对应的实现方法，第1件事和第3件事放在了装饰器中，每次去装饰一个穿搭方案，是不是很灵活）。
还有，很多博文中有讲到，由于继承为类引入静态特征(编译期确定了)，并且随着扩展功能的增多，会导致子类数目的急剧增多，子类会很膨胀，但装饰器模式，也会根据实际场景生成很多个ConcretComponent，其实也形成很多零散的类。。。。我倒是没发现有什么区别，当然如果你有好的证明请一定要给我留言。。

java中IO流是装饰器的一个很好的案例。下面我们来撸一下。

BufferdInputStream in =new BufferdInputStream(new FileInPutStream(new File("xxxx")))

最后一句话总结：
被装饰器对象ConcreteComponent 和装饰对象ConcreteDecorter实现统一Component接口，重写对应方法；并且装饰对象拥有被装饰器对象的引用（属性），且以其构造装饰对象，；在不改变被装饰对象方法情况下，装饰器对象对被装饰对象包装，实现了方法的覆盖（本质上是它们都重写了接口方法，装饰对象重写方法一般比被装饰对象重写方法功能更强），并且，在装饰器对象中，可以通过super.被装饰器对象.方法（），来调用被装饰器对象的方法。

啊~我要吸点氧，这个一句话有点长。
拜了个拜~~~~