《JAVA与模式》之装修者模式

装饰者模式

动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

具体被装饰者和抽象装饰类都继承于抽象被装饰者类，继承的是类型，而不是行为。行为来自装饰者和基础组件，或与其他装饰者之间的组合关系。

装饰模式的角色

　　抽象构件角色（Component）：给出一个抽象接口，以规范准备接收附加责任的对象。

　　具体构件角色（Concrete Component）：定义将要接收附加责任的类。

　　装饰角色（Decorator）：持有一个构件（Component）对象的引用，并定义一个与抽象构件接口一致的接口。

　　具体装饰角色（Concrete Decorator）：负责给构件对象“贴上”附加的责任。

装饰模式的特点

　　装饰对象和真实对象有相同的接口。这样客户端对象就可以以和真实对象相同的方式和装饰对象交互。

　　装饰对象包含一个真实对象的引用（reference）。

　　装饰对象接收所有来自客户端的请求，它把这些请求转发给真实的对象。

　　装饰对象可以在转发这些请求之前或之后附加一些功能。

　　这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能。

 

代码

public class Zhuangxiuzhe {
    public static void main(String[] args) {
        Zhuangxiuzhe zhuangxiuzhe=new Zhuangxiuzhe();
        Component component=zhuangxiuzhe.new ConcreteComponent();
        Component decorator=zhuangxiuzhe.new ConcreteDecorator1(component);
        decorator.doMethod();
        Component decorator2=zhuangxiuzhe.new ConcreteDecorator2(decorator);
        decorator2.doMethod();
        
    }

    interface Component {

        public void doMethod();

    }

    class ConcreteComponent implements Component {

        public void doMethod() {
            System.out.println("一般操作");

        }

    }
    abstract class  Decorator implements Component{
        
        protected Component component;
        public Decorator(Component component){
            this.component=component;
        }
            
        
    }
    class ConcreteDecorator1 extends Decorator{

        public ConcreteDecorator1(Component component) {
            super(component);
            
        }
        public void test1(){
            System.out.println("ConcreteDecorator1 额外操作");
        }

        public void doMethod() {
            super.component.doMethod();
            test1();
        }
    }
    class ConcreteDecorator2 extends Decorator{
        
        public ConcreteDecorator2(Component component) {
            super(component);
            
        }
        
        public void doMethod() {
            super.component.doMethod();
            test2();
        }
        
        public void test2(){
            System.out.println("ConcreteDecorator2 额外操作");
        }
    }
    

}

执行结果

一般操作
ConcreteDecorator1 额外操作
一般操作
ConcreteDecorator1 额外操作
ConcreteDecorator2 额外操作

---

 

 突然发现装修者模式跟责任链模式有点相同,自身都引用了抽象类,这样可以调用传入的包装类

区别在于功能上:责任链强调的是请求由谁来处理,而装修者模式则是对引入的对象的现有功能进行包装,增强改变

Java IO中的装饰模式

　　在IO中，具体构件角色是节点流，装饰角色是过滤流。

　　FilterInputStream和FilterOutputStream是装饰角色，而其他派生自它们的类则是具体装饰角色。

我们来看看代码

抽象角色类InputStream

public abstract class InputStream implements Closeable {


//实现了read等方法
public int read(byte b[]) throws IOException {
    return read(b, 0, b.length);
    }

}

具体角色类FileInputStream

public
class FileInputStream extends InputStream{


}

抽象包装类FilterInputStream

public
class FilterInputStream extends InputStream {
    /**
     * The input stream to be filtered. 
     */
    protected volatile InputStream in;


protected FilterInputStream(InputStream in) {
    this.in = in;
    }

 public int read() throws IOException {
    return in.read();
    }


}

具体包装类BufferedInputStream

public
class BufferedInputStream extends FilterInputStream {

public BufferedInputStream(InputStream in) {
    this(in, defaultBufferSize);
    }

//完成了设置抽象角色类的映射
 public BufferedInputStream(InputStream in, int size) {
    super(in);
        if (size <= 0) {
            throw new IllegalArgumentException("Buffer size <= 0");
        }
    buf = new byte[size];
    }

//read方法中调用fill()
 public synchronized int read() throws IOException {
    if (pos >= count) {
        fill();
        if (pos >= count)
        return -1;
    }
    return getBufIfOpen()[pos++] & 0xff;
    }
 private void fill() throws IOException {
        byte[] buffer = getBufIfOpen();
    if (markpos < 0)
        pos = 0;        /* no mark: throw away the buffer */
    else if (pos >= buffer.length)    /* no room left in buffer */
        if (markpos > 0) {    /* can throw away early part of the buffer */
        int sz = pos - markpos;
        System.arraycopy(buffer, markpos, buffer, 0, sz);
        pos = sz;
        markpos = 0;
        } else if (buffer.length >= marklimit) {
        markpos = -1;    /* buffer got too big, invalidate mark */
        pos = 0;    /* drop buffer contents */
        } else {        /* grow buffer */
        int nsz = pos * 2;
        if (nsz > marklimit)
            nsz = marklimit;
        byte nbuf[] = new byte[nsz];
        System.arraycopy(buffer, 0, nbuf, 0, pos);
                if (!bufUpdater.compareAndSet(this, buffer, nbuf)) {
                    // Can't replace buf if there was an async close.
                    // Note: This would need to be changed if fill()
                    // is ever made accessible to multiple threads.
                    // But for now, the only way CAS can fail is via close.
                    // assert buf == null;
                    throw new IOException("Stream closed");
                }
                buffer = nbuf;
        }
        count = pos;
    int n = getInIfOpen().read(buffer, pos, buffer.length - pos);
        if (n > 0)
            count = n + pos;
    }


}

fill()方法中除了自身操作外,我们看到了 int n = getInIfOpen().read(buffer, pos, buffer.length - pos);

 private InputStream getInIfOpen() throws IOException {
        InputStream input = in;
    if (input == null)
        throw new IOException("Stream closed");
        return input;
    }

在看看getInIfOpen()方法,我们就明白了 整个的过程

 

参考地址:

http://www.cnblogs.com/mengdd/archive/2013/02/12/2910302.html

http://blog.csdn.net/cai1213/article/details/8003445

http://xubindehao.iteye.com/blog/474636