关于设计一个容器过程中碰到的问题

经过再三考虑，决定用如下的策略：
只要是经过容器构造出来的组建实例，一定是CGLib Enhance过的，组件之间互相调用，传递的也一定是诸如demo.UserManager$$EnhancerByCGLIB$$ce637350@189635d这样的instance，如果有迫不得已情况，可以从Enhanced对象获得未保护的对象(即demo.UserManager@1234567)。

这样的副作用是：所有东东都是CGLib D.P.，就是不知道性能会有多大的影响:(

Potian大 虾呢？？？你在那里。。。。。

那不就完了？只要你能够控制传递进去的user类型，不管你用什么方法，你提出的问题不就是没有意义的了？你要问什么？

说说我的理解：
总是存在一个“知道”的问题。

对于一个传递进来的对象，我究竟可以知道多少？

按照ajoo最为强调的面向接口的编程思路，传递进来的一定是一个接口。
你对于这个接口的使用，永远只能是：
xxx.setName()之类，
而不应该是：
u.getEntity().setName();

因为如果这两个对象无论是否经过AOP的增强，都一定会有setName()，但是不见得会有getEntity()。

而且作为调用来说，你也只需要管调用这个setName()；不需要去管这个setName()还会不会去做别的事情。

只需要知道接口，别的就不用管了。

的确，在使用传递进来的User参数的时候，按照面向接口的原则，只应该知道该接口放出来了那些方法，但是接口只定义了输入参数和输出，并没有描述行为。
比如

/**
 * Set user's name and save automatically
 * @param String username to set
 */
  public void setName(String username);;

/**
 * Set user's name, remeber, you must invoke UserManager#saveUser(User); to save user's modified data manually
 * @param String username to set
 */
  public void setName(String username);;

上面的接口是一样的，但是行为不一样，而恰恰是行为不同，影响了调用者的行为。
所以程序员在写上面这个UserManager.addMember()函数的时候，完全有可能采取不同的行为。

在没有使用AOP的时候，setName要么自动save，要么不。但是有了AOP，是否自动Save可以在后期运行态的时候动态确定了，这样对于addMember这样相对"静态"的代码，就不好处理了。这就是我感到比较困惑的地方。

pulic class Foo{
  private int c=0;
  public String getName();{
    if(c==0);{
      return "Foo";
    } else {
      return "Food";
    }
  }
......
  public void setC(int newC);{
    c=newC;
  }
}

假设这样一个类，其中的getName随着c的不同，会返回不同的值，你怎么办？

所有的类，对外都不过是一个调用的接口，如果你一定要知道他究竟会做什么，才能正确的调用他，那么你的总体设计一定是有问题的。

不错。面向接口，就是要面向一个统一的形式。具体的实现语义如何，由组装者决定，使用者绝对不应该操心。