代理模式和装饰模式

http://www.cnblogs.com/jaredlam/archive/2011/11/08/2241089.html

学习AOP时，教材上面都说使用的是动态代理，可是在印象中代理模式一直都是控制访问什么的，怎么又动态增加行为了，动态增加行为不是装饰器模式吗？于是 找了很多资料，想弄清楚这两者之间到底有什么区别。结果发现这一篇英文文章讲的很清晰，就翻译一下，供参考。       

        首先，让我们先看一下下面的这两个UML类图，他们分别描述了装饰器模式和代理模式的基本实现。

                   

                    

        这两个图可能使我们产生困惑。这两个设计模式看起来很像。对装饰器模式来说，装饰者（decorator）和被装饰者（decoratee）都实现同一个 接口。对代理模式来说，代理类（proxy class）和真实处理的类（real class）都实现同一个接口。此外，不论我们使用哪一个模式，都可以很容易地在真实对象的方法前面或者后面加上自定义的方法。

        然而，实际上，在装饰器模式和代理模式之间还是有很多差别的。装饰器模式关注于在一个对象上动态的添加方法，然而代理模式关注于控制对对象的访问。换句话 说，用代理模式，代理类（proxy class）可以对它的客户隐藏一个对象的具体信息。因此，当使用代理模式的时候，我们常常在一个代理类中创建一个对象的实例。并且，当我们使用装饰器模 式的时候，我们通常的做法是将原始对象作为一个参数传给装饰者的构造器。

        我们可以用另外一句话来总结这些差别：使用代理模式，代理和真实对象之间的的关系通常在编译时就已经确定了，而装饰者能够在运行时递归地被构造。    

代理模式：

//代理模式
public class Proxy implements Subject{

       private Subject subject;
       public Proxy(){
             //关系在编译时确定
            subject = new RealSubject();
       }
       public void doAction(){
             ….
             subject.doAction();
             ….
       }
}

//代理的客户
public class Client{
        public static void main(String[] args){
             //客户不知道代理委托了另一个对象
             Subject subject = new Proxy();
             …
        }
}

装饰模式：

//装饰器模式
public class Decorator implements Component{
        private Component component;
        public Decorator(Component component){
            this.component = component
        }
       public void operation(){
            ….
            component.operation();
            ….
       }
}

//装饰器的客户
public class Client{
        public static void main(String[] args){
            //客户指定了装饰者需要装饰的是哪一个类
            Component component = new Decorator(new ConcreteComponent());
            …
        }
}

准备知识 

在OO设计领域，我们知道前人总结了不少的经验，许多的经验在现代软件工程过程中已经被认为是原则来遵守。下面笔者摘抄几项下文涉及到的OO原则的定义。 

OCP（开闭原则，Open-ClosedPrinciple）：一个软件的实体应当对扩展开放，对修改关闭。我的理解是，对于一个已有的软件，如果需要扩展，应当在不需修改已有代码的基础上进行。 

DIP（依赖倒转原则，Dependence InversionPrinciple）：要针对接口编程，不要针对实现编程。我的理解是，对于不同层次的编程，高层次暴露给低层次的应当只是接口，而不是它的具体类。 

LoD（迪米特法则，Law ofDemeter）：只与你直接的朋友通信，而避免和陌生人通信。众所周知类（或模块）之间的通信越少，耦合度就越低，从而更有利于我们对软件的宏观管理。

LSP里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现

1.谈谈你对IoC的理解

答：IoC即控制反转，反转的类之间的依赖关系。通过反转，让依赖方被动地

等待外层注入被依赖的类，而不是自己去主动寻找。这样就可以为依赖方注入

不同的实现，从而使程序更加灵活，易于改动和测试。

5.接口和抽象类的区别

答：语法上接口只能有方法声明和常量，而抽象类可以有变量以及实现了的方法。

从用法上来说，接口就像契约，是一种对应用程序应该提供的功能的约定。而抽象

类是对接口的部分实现，未实现部分实际上是延迟到了子类去实现。（同时还谈了

谈以前用过的适配器模式）

3.UML中的用例图和时序图都是用来做什么的？

答：一个用例图一般代表对应用户需求的一个功能描述，（有些像敏捷开发中的

用户故事，在心里想的，记不清了没有说），而时序图可以用来表示类或者组件间

的调用关系，可以清楚地看出程序是如何运行的。