对象去耦(Object decoupling)

    代理（Proxy）模式和状态（State）模式分别提供了供你使用的代理类(surrogate class)；正真干活的那个类被代理类隐藏了。当你调用代理类的一个方法的时候，代理类只是简单的调用实现类（implementing class）所对应的方法。这两种模式非常相似，实际上，代理（Proxy）模式只是状态(State)模式的一个特例。

    有人试图将这两种模式合在一起统称为Surrogate模式，但是“代理（proxy）”这个术语已经用了很长时间了，而且它有自己特殊的含义，它的这些含义基本上体现了这两种模式的差别所在。

    这两种模式的基本概念非常简单：代理类 (surrogate) 和 实现类都由同一个基类派生出来：

    当创建一个代理对象 (surrogate object) 时，同时会创建一个实现（对象），代理对象会把所有的方法调用传递给实现对象。

    从结构上看，代理（Proxy）模式和状态（State）模式之间的差别非常简单：一个代理（Proxy）只对应一个实现（implementation），而一个状态（State）却可以对应多个实现。《设计模式》一书认为，这两种两种模式的应用场合是截然不同的：代理（Proxy）模式用于控制对实现（类）的访问，而状态（State）模式可以动态地改变实现（类）。但是，如果把“控制对实现类的访问”这个概念扩展开来的话，这两种模式就可以优雅的结合在一起了。

代理：替另外一个对象打点一切(Proxy: fronting for another object)

    我们按照上面的图示实现代理（Proxy）模式，下面是实现代码：

 

//: proxy:ProxyDemo.java

// Simple demonstration of the Proxy pattern.

package proxy;

import junit.framework.*;

 

interface ProxyBase {

 void f();

 void g();

 void h();

}

 

class Proxy implements ProxyBase {

 private ProxyBase implementation;

 public Proxy() {

  implementation = new Implementation();

 }

 // Pass method calls to the implementation:

 public void f() { implementation.f(); }

 public void g() { implementation.g(); }

 public void h() { implementation.h(); }

}

 

class Implementation implements ProxyBase {

 public void f() {

  System.out.println("Implementation.f()");

 }

 public void g() {

  System.out.println("Implementation.g()");

 }

 public void h() {

  System.out.println("Implementation.h()");

 }

}

 

public class ProxyDemo extends TestCase  {

 Proxy p = new Proxy();

 public void test() {

  // This just makes sure it will complete

  // without throwing an exception.

  p.f();

  p.g();

  p.h();

 }

 public static void main(String args[]) {

  junit.textui.TestRunner.run(ProxyDemo.class);

 }

} ///:~

    当然，并不是说实现类和代理类必须实现完全相同的接口；既然代理类只是在一定程度上代表那个需要它提交(referring)方法的类，这就已经满足了proxy模式的基本要求（注意这里的陈述和GoF一书所给出的定义是有差别的）。尽管如此，定义一个公共的接口还是很方便的，这样就可以强制实现类（Implementation）实现（fulfill）代理类（Proxy）需要调用的所有方法。

用Proxy模式实现PoolManager

//: proxy:PoolManager.java

package proxy;

import java.util.*;

 

public class PoolManager {

 private static class PoolItem {

  boolean inUse = false;

  Object item;

  PoolItem(Object item) { this.item = item; }

 }

 public class ReleasableReference {  // Used to build the proxy

  private PoolItem reference;

  private boolean released = false;

  public ReleasableReference(PoolItem reference) {

   this.reference = reference;

  }

  public Object getReference() {

   if(released)

    throw new RuntimeException(

    "Tried to use reference after it was released");

   return reference.item;

  }

  public void release() {

   released = true;

   reference.inUse = false;

  }

 }

 private ArrayList items = new ArrayList();

 public void add(Object item) {

  items.add(new PoolItem(item));

 }

 // Different (better?) approach to running out of items:

 public static class EmptyPoolItem {}

 public ReleasableReference get() {

  for(int i = 0; i < items.size(); i++) {

   PoolItem pitem = (PoolItem)items.get(i);

   if(pitem.inUse == false) {

    pitem.inUse = true;

    return new ReleasableReference(pitem);

   }

  }

  // Fail as soon as you try to cast it:

  // return new EmptyPoolItem();

  return null; // temporary

 }

} ///:~

 

 

//: proxy:ConnectionPoolProxyDemo.java

package proxy;

import junit.framework.*;

 

interface Connection {

 Object get();

 void set(Object x);

 void release();

}

 

class ConnectionImplementation implements Connection {

 public Object get() { return null; }

 public void set(Object s) {}

 public void release() {} // Never called directly

}

 

class ConnectionPool { // A singleton

 private static PoolManager pool = new PoolManager();

 private ConnectionPool() {} // Prevent synthesized constructor

 public static void addConnections(int number) {

  for(int i = 0; i < number; i++)

   pool.add(new ConnectionImplementation());

 }

 public static Connection getConnection() {

  PoolManager.ReleasableReference rr =

   (PoolManager.ReleasableReference)pool.get();

  if(rr == null) return null;

  return new ConnectionProxy(rr);

 }

 // The proxy as a nested class:

 private static

 class ConnectionProxy implements Connection {

  private PoolManager.ReleasableReference implementation;

  public

   ConnectionProxy(PoolManager.ReleasableReference rr) {

    implementation = rr;

   }

   public Object get() {

    return

     ((Connection)implementation.getReference()).get();

   }

   public void set(Object x) {

    ((Connection)implementation.getReference()).set(x);

   }

   public void release() { implementation.release(); }

 }

}

 

public class ConnectionPoolProxyDemo extends TestCase {

 static {

  ConnectionPool.addConnections(5);

 }

 public void test() {

  Connection c = ConnectionPool.getConnection();

  c.set(new Object());

  c.get();

  c.release();

 }

 public void testDisable() {

  Connection c = ConnectionPool.getConnection();

  String s = null;

  c.set(new Object());

  c.get();

  c.release();

  try {

   c.get();

  } catch(Exception e) {

   s = e.getMessage();

   System.out.println(s);

  }

  assertEquals(s,

   "Tried to use reference after it was released");

 }

 public static void main(String args[]) {

  junit.textui.TestRunner.run(

   ConnectionPoolProxyDemo.class);

 }

} ///:~

动态代理（Dynamic Proxies）

    JDK1.3引入了动态代理 (Dynamic Proxy). 尽管一开始有些复杂，但它确实是一个吸引人的工具。下面这个有趣的小例子证明了这一点， 当invocation handler被调用的时候，代理机制（proxying）开始工作。这是非常Cool的一个例子，它就在我的脑海里，但是我必须得想出一些合理的东西给invocation handler，这样才能举出一个有用的例子…(作者还没有写完)

// proxy:DynamicProxyDemo.java

// Broken in JDK 1.4.1_01

package proxy;

import java.lang.reflect.*;

 

interface Foo {

 void f(String s);

 void g(int i);

 String h(int i, String s);

}

 

public class DynamicProxyDemo {

 public static void main(String[] clargs) {

  Foo prox = (Foo)Proxy.newProxyInstance(

   Foo.class.getClassLoader(),

   new Class[]{ Foo.class },

   new InvocationHandler() {

    public Object invoke(

     Object proxy, Method method,

     Object[] args) {

      System.out.println(

       "InvocationHandler called:" +

       "\n\tMethod = " + method);

      if (args != null) {

       System.out.println("\targs = ");

       for (int i = 0; i < args.length; i++)

        System.out.println("\t\t" + args[i]);

      }

      return null;

     }

   });

  prox.f("hello");

  prox.g(47);

  prox.h(47, "hello");

 }

} ///:~

练习：用java的动态代理创建一个对象作为某个简单配置文件的前端。例如，在good_stuff.txt文件里有如下条目：

a=1

b=2

c="Hello World"

客户端程序员可以使用（你写的）NeatPropertyBundle类：

NeatPropertyBundle p =

  new NeatPropertyBundle("good_stuff");

System.out.println(p.a);

System.out.println(p.b);

System.out.println(p.c);

配置文件可以包含任何内用，任意的变量名。动态代理要么返回对应属性的值要么告诉你它不存在（可能通过返回null）。如果你摇设置一个原本不存在的属性值，动态代理会创建一个新的条目。ToString()

方法应该显示当前的所有条目。 

练习：和上一道练习类似，用Java的动态代理连接一个DOS的Autoexec.bat文件。 

练习：接受一个可以返回数据的SQL查询语句，然后读取数据库的元数据（metadata）。为每一条记录（record）提供一个对象，这个对象拥有一下属性：列名(column names)和对应的数据类型(data types). 

练习：用XML-RPC写一个简单的服务器和客户端.每一个客户端返回的对象都必须使用动态代理的概念（dynamic proxy concept）来实现（exercise）远端的方法。（瞎翻的，不知道啥意思）

读者Andrea写道：

    除了最后一个练习，我觉得你给出的上面几个练习都不咋的。我更愿意把Invocation handler看成是能和被代理对象正交的 (orthogonal) 东东。

    换句话说，invocation handler的实现应该是和动态创建的代理对象所提供的那些接口完全无关的。也就是说，一旦invocation handler写好之后，你就可以把它用于任何暴露接口的类，甚至是那些晚于invocation handler出现的类和接口。

    这就是我为什么要说invocation handler所提供的服务是和被代理对象正交的(orthognal)。Rickard 在他的SmartWorld例子里给出了几个handler，其中我最喜欢的是那个调用－重试(call-retry)handler。它首先调用那个（被代理的）实际对象，如果调用产生异常或者等待超时，就重试三次。如果这三次都失败了，那就返回一个异常。这个Handler可以被用于任何一个类。

    那个handler的实现相对于你这里讲的来说过于复杂了，我用这个例子仅仅是想说明我所指的正交（orthogonal）服务到底是什么意思。

    您所给出的那几个练习，在我看来，唯一适合用动态代理实现的就是最后那个用XML-RPC与对象通信的那个练习。因为你所使用的用以分发消息的机制（指XML-RPC）是和你想要建立通信的那个对象完全正交的。

状态模式：改变对象的行为(State: changing object behavior)

    一个用来改变类的（状态的）对象。

    迹象：几乎所有方法里都出现（相同的）条件（表达式）代码。

    为了使同一个方法调用可以产生不同的行为，状态（State）模式在代理（surrogate）的生命周期内切换它所对应的实现（implementation）。当你发现，在决定如何实现任何一个方法之前都必须作很多测试的情况下，这是一种优化实现代码的方法。例如，童话故事青蛙王子就包含一个对象（一个生物），这个对象的行为取决于它自己所处的状态。你可以用一个布尔（boolean）值来表示它的状态，测试程序如下： 

//: state:KissingPrincess.java

package state;

import junit.framework.*;

 

class Creature {

 private boolean isFrog = true;

 public void greet() {

  if(isFrog)

   System.out.println("Ribbet!");

  else

   System.out.println("Darling!");

 }

 public void kiss() { isFrog = false; }

}

 

public class KissingPrincess extends TestCase  {

 Creature creature = new Creature();

 public void test() {

  creature.greet();

  creature.kiss();

  creature.greet();

 }

 public static void main(String args[]) {

  junit.textui.TestRunner.run(KissingPrincess.class);

 }

} ///:~

    但是，greet() 方法（以及其它所有在完成操作之前必须测试isFrog值的那些方法）最终要产生一大堆难以处理的代码。如果把这些操作都委托给一个可以改变的状态对象（State object），那代码会简单很多。

//: state:KissingPrincess2.java

package state;

import junit.framework.*;

 

class Creature {

 private interface State {

  String response();

 }

 private class Frog implements State {

  public String response() { return "Ribbet!"; }

 }

 private class Prince implements State {

  public String response() { return "Darling!"; }

 }

 private State state = new Frog();

 public void greet() {

  System.out.println(state.response());

 }

 public void kiss() { state = new Prince(); }

}

 

public class KissingPrincess2 extends TestCase  {

 Creature creature = new Creature();

 public void test() {

  creature.greet();

  creature.kiss();

  creature.greet();

 }

 public static void main(String args[]) {

  junit.textui.TestRunner.run(KissingPrincess2.class);

 }

} ///:~

    此外，状态（State）的改变会自动传递到所有用到它的地方，而不需要手工编辑类的方法以使改变生效。

 下面的代码演示了状态（State）模式的基本结构。

//: state:StateDemo.java

// Simple demonstration of the State pattern.

package state;

import junit.framework.*;

 

interface State {

 void operation1();

 void operation2();

 void operation3();

}

 

class ServiceProvider {

 private State state;

 public ServiceProvider(State state) {

  this.state = state;

 }

 public void changeState(State newState) {

  state = newState;

 }

 // Pass method calls to the implementation:

 public void service1() {

  // ...

  state.operation1();

  // ...

  state.operation3();

 }

 public void service2() {

  // ...

  state.operation1();

  // ...

  state.operation2();

 }

 public void service3() {

  // ...

  state.operation3();

  // ...

  state.operation2();

 }

}

 

class Implementation1 implements State {

 public void operation1() {

  System.out.println("Implementation1.operation1()");

 }

 public void operation2() {

  System.out.println("Implementation1.operation2()");

 }

 public void operation3() {

  System.out.println("Implementation1.operation3()");

 }

}

 

class Implementation2 implements State {

 public void operation1() {

  System.out.println("Implementation2.operation1()");

 }

 public void operation2() {

  System.out.println("Implementation2.operation2()");

 }

 public void operation3() {

  System.out.println("Implementation2.operation3()");

 }

}

 

public class StateDemo extends TestCase  {

 static void run(ServiceProvider sp) {

  sp.service1();

  sp.service2();

  sp.service3();

 }

 ServiceProvider sp =

  new ServiceProvider(new Implementation1());

 public void test() {

  run(sp);

  sp.changeState(new Implementation2());

  run(sp);

 }

 public static void main(String args[]) {

  junit.textui.TestRunner.run(StateDemo.class);

 }

} ///:~

    在main()函数里，先用到的是第一个实现，然后转入第二个实现。

    当你自己实现State模式的时候就会碰到很多细节的问题，你必须根据自己的需要选择合适的实现方法，比如用到的状态（State）是否要暴露给调用的客户，以及如何使状态发生变化。有些情况下（比如Swing的LayoutManager），，客户端可以直接传对象进来，但是在KissingPrincess2.java那个例子里，状态对于客户端来说是不可见的。此外，用于改变状态的机制可能很简单也可能很复杂－比如本书后面将要提到的状态机（State Machine），那里会讲到一系列的状态以及改变状态的不同机制。

     上面提到Swing的LayoutManager那个例子非常有趣，它同时体现了Strategy模式和State模式的行为。

    Proxy模式和State模式的区别在于它们所解决的问题不同。《设计模式》里是这么描述Proxy模式的一般应用的：

1.  远程代理(Remote Proxy)为一个对象在不同的地址空间提供局部代理。A remote proxy is created for you automatically by the RMI compiler rmic as it creates stubs and

2.  虚代理（Virtual proxy），根据需要，在创建复杂对象时使用“lazy initialization” .

3.  保护代理(protection proxy) 用于你不希望客户端程序员完全控制被代理对象（proxied object）的情况下。

4.  智能引用（smart reference）. 当访问被代理对象时提供额外的动作。例如，它可以用来对特定对象的引用进行计数，从而实现copy-on-write，进而避免对象别名（object aliasing）. 更简单的一个例子是用来记录一个特定方法被调用的次数。

    你可以把java里的引用（reference）看作是一种保护代理，它控制对分配在堆(heap)上的实际对象的访问（而且可以保证你不会用到一个空引用（null reference））。 

    【重写：在《设计模式》一书里，Proxy模式和State模式被认为是互不相干的，因为那本书给出的用以实现这两种模式的结构是完全不同的（我认为这种实现有点武断）。尤其是State模式，它用了一个分离的实现层次结构，但我觉着完全没有必要，除非你认定实现代码不是由你来控制的（当然这也是一种可能的情况，但是如果代码是由你来控制的，那还是用一个单独的基类更简洁实用）。此外，Proxy模式的实现不需要用一个公共的基类，因为代理对象只是控制对被代理对象的访问。尽管有细节上的差异，Proxy模式和State模式都是用一个代理（surrogate）把方法调用传递给实现对象。】 

    State模式到处可见，因为它是最基本的一个想法，比如，在Builder模式里，“Director”就是用一个后端（backend）的Buider object来产生不同的行为。

迭代器：分离算法和容器（Iterators: decoupling algorithms from containers）

    Alexander Stepanov（和Dave Musser一起）写STL以前 ，已经用了好几年思考泛型编程（generic programming）的问题。最后他得出结论：所有的算法都是定义在代数结构（algebraic structures）之上的-我们把代数结构称作容器（container）。

    在这个过程中，他意识到i迭代器对于算法的应用是至关重要的，因为迭代器将算法从它所使用的特定类型的容器中分离出来。这就意味着在描述算法的时候，可以不必考虑它所操作的特定序列。更为一般情况，用迭代器写的任何代码都与它所操作的数据结构相分离，这样一来这些代码就更为通用并且易于重用。

    迭代器的另外一个应用领域就是函数式编程（functional programming），它的目标是描述程序的每一步是干什么的，而不是描述程序的每一步是怎么做的。也就是说，使用“sort”（来排序），而不是具体描述排序的算法实现。C++STL的目的就是为C++语言提供对这种泛型编程方法的支持(这种方法成功与否还需要时间来验证)。

    如果你用过Java的容器类（写代码不用到它们是很难的），那你肯定用过迭代器－Java1.0/1.1把它叫作枚举器（Enumeration），Java2.0叫作迭代器－你肯定已经熟悉它们的一般用法。如果你还不熟悉的话，可以参考Thinking in Java 第二版第九章 (可以从 www.BruceEckel.com免费下载).

    因为Java2的容器非常依赖于迭代器，所以它们就成了泛型编程/函数式编程的最佳候选技术。这一章节通过把STL移植到Java来讲解这些技术，（移植的迭代器）会和Java2的容器类一起使用。

类型安全的迭代器（Type-safe iterators）

    在Thinking in Java 第二版里，我实现了一个类型安全的容器类，它只接受某一特定类型的对象。读者Linda Pazzaglia想要我实现另外一个类型安全的组件，一个可以和java.util里定义的容器类兼容的迭代器，但要限制它所遍历的对象必须都是同一类型的。

    如果Java有模板（template）机制，上面这种（类型安全的）迭代器很容易就可以返回某一特定类型的对象。但是没有模板机制，就必须得返回generic Objects，或者为每一种需要遍历的对象都手工添加代码。这里我会使用前一种方法。

    另外一个需要在设计时决定的问题（design decision）是什么时候判定对象的类型。一种方法是以迭代器遍历的第一个对象的类型（作为迭代器的类型），但是这种方法当容器类根据它自己的内部算法（比如hash表）重新为对象排序时就会有问题，这样同一迭代器的两次遍历就可能得到不同的结果。安全的做法是在构造迭代器的时候让用户指定迭代器的类型。

    最后的问题是如何构建迭代器。我们不可能重写现有的Java类库，它已经包含了枚举器和迭代器。但是，我们可以用Decorator模式简单的创建一个枚举器或者迭代器的外覆类，产生一个具有我们想要的迭代行为（本例中，指在类型不正确的时候抛出RuntimeException异常）的新对象，而这个新对象跟原来的枚举器或者迭代器有相同的接口，这样一来，它就可以用在相同的场合（或许你会争论说这实际上是Proxy模式，但是从它的目的（intent）来说它更像Decorator模式）。

实现代码如下:

//: com:bruceeckel:util:TypedIterator.java

package com.bruceeckel.util;

import java.util.*;

 

public class TypedIterator implements Iterator {

 private Iterator imp;

 private Class type;

 public TypedIterator(Iterator it, Class type) {

  imp = it;

  this.type = type;

 }

 public boolean hasNext() {

  return imp.hasNext();

 }

 public void remove() { imp.remove(); }

 public Object next() {

  Object obj = imp.next();

  if(!type.isInstance(obj))

   throw new ClassCastException(

   "TypedIterator for type " + type +

   " encountered type: " + obj.getClass());

  return obj;

 }

} ///:~

 

练习：

1．写一个“virtual proxy”。

2．写一个“Smartreference”代理，用这个代理记录某个特定对象的方法调用次数。

3．仿照某个DBMS系统，写一个程序限制最大连接数。用类似于singleton的方法控制连接对象的数量。当用户释放某个连接时，必须通知系统将释放的连接收回以便重用。为了保证这一点，写一个proxy对象代替对连接的引用计数，进一步设计这个proxy使它能够将连接释放回系统。

4．用State模式，写一个UnpredictablePerson类，它根据自己的情绪（Mood）改变对hello（）方法的响应。再写一个额外的Mood类：Prozac。

5．写一个简单的copy-on write实现。

6.java.util.Map 没有提供直接从一个两维数组读入“key-value”对的方法。写一个adapter类实现这个功能。

7．Create an Adapter Factory that dynamically finds and produces the adapter that you need to connect a given object to a desired interface.

8．用java标准库的动态代理重做练习7。

9．改写本节的Object Pool，使得对象再一段时间以后自动回收到对象池。

10．改写练习9，用“租借（leasing）”的方法使得客户端可以刷新“租借对象”，从而阻止对象定时自动释放。

11．考虑线程因素，重写Object Pool。

发表于 @ 2004年08月06日 08:48:00|评论(loading...)|编辑