贫血就贫血,咂地?

嗯。。。还是缺乏例子和论据呀。

1。你想把aspect作为语言的一部分？太理想化了。aspect目前还不是first class citizen。要想这么做，障碍很多，不是一个良好的愿望就可以的。
我说的灵活性完全适用于aop么？要不是你没看懂我说的灵活性，要不是你太乐观了。你最好举个例子。空口说“完全适用”没有说服力。这些灵活性在aspect不能成为一等公民的情况下不是那么容易达到的。

2。你不就是认为spring+aop两者算一个东西吗？但是我也说明了，即使你这么认为，它也仍然不够灵活。aspect调用spring的代码本身就是service locator，一些本来可以用容器可以配置的注射策略此处却无法配置。

3。这种设计没有ioc框架也一样有效。没有spring, pico前人们早就在做ioc，并且这么做了很多年。


结论：
1。你的“单点”维护几乎没有意义。只是节省了几个factory的声明，不节省真正的逻辑和代码。相反，反而增加了一个aspect和一堆过程化的service locator代码。
2。你说的“独立”单元测试，是你自己设置的概念。大多数人在说独立的时候都不会认为被迫绑着一个aop还能叫“独立”。
3。aop的破坏可读性，破坏可维护性的缺点你没有给出任何有力的辩护。
4。那个aspect代码要是算作配置的一部分的话，却缺乏可配置性。

比喻不贴切。

OO是一个完整的概念。在OO语言里面，概念的唯一主体是对象，所有对象都有完全一致的动态语义模型。本身就没有引入额外的东西，它和汇编本身就是两种语言。
而aop，除非你能脱离oo，直接用aop写东西，否则你就是混合了aspect和object两种互相不融合的东西。

至于说静态的，这么说吧，先举个例子：

Service tx(int level, Service service);{
  return new TransactionalService(service, level);;
}

1。这个tx函数可以被任何java代码调用。
2。它的功能是给某个Service对象增加某一个isolation level的事务控制。
3。这个level是可以动态改变的。
比如:

tx(1);;
tx(factorial(10););;

等等。

你能不能给出一个同等的aspect先？这个aspect要能够接受参数（有点感觉象gp），同时这个参数必须是能够在动态从java代码中传递进来。

1。是的麻烦你把你的灵活性show一下。最好是实际的例子，别来虚的，否则没有意义。看看这种灵活性在实际项目中到底是如何灵活的......
2。我认不认为spring+aop两者算一个东西,同讨论的主题无关，你也没必要猜。
3。在没有IOC之前，我只需要对smtpService接口提供工厂，而不是domain对象。
针对结论：
1。我也可以采用你同样的论证方式，“简单的情况当然看不出效果，如果很多呢？”，单点维护的意义就会越明显。你指责我多用了aspect和servicelocator是没有意义的，这就好比你觉得玩橄榄球的人很可笑，干嘛球不是圆的呢，篮球多圆？你不也多个factory和proxy吗？
2。好了，退一步说，就算你认为我测试需要绑定aspectJ，那又如何呢？我就不能很好的测试了？我就达不到单元测试的目的了？单元测试就必须要完全“独立”？只要这种足够的简单，没啥不可以的。
3。我根本不需要辩护，因为你完全没有证据证明是AOP天生的破坏了可维护性。相反倒是认为错用了AOP的人导致了混乱。
4。你想要配置啥？

嗯,是不太贴切，但是就不能领会精神吗? 我如果说C和C++你不会有意见吧？
砸就不相容了呢？aspect不过就是特殊的class吗？C++还没反射勒，这你咋说？
aspect是对OO的补充。当然兼容OO.

你说的这个例子能否告诉我在aspect中必须要能够接受参数（有点感觉象gp），同时这个参数必须是能够在动态从java代码中传递进来的原因？
不要光告诉我怎么做，给点创造的空间。
同时也请你展示一下，你的方案是如何动态的，好吗？说老实话，我还不理解你的意图。

两位不要刷贴了，做一些无谓的争论。

给ajoo看xiecc同志帖子，我想说的是：做框架的人做的不到位啊，让写应用的人这么难受。xiecc同志在配置文件XML中已经对框架明确声明了依赖关系，用到依赖的时候却得自己搞定。这本就是一种畸形的东西（partech再不要支持这种AOP也罢），ajoo同志不反思框架的失职，而对此种注入大加批评，呵呵，不是严于律自，宽于待人的态度啊

因此这场辩论本质上就是不平等的，现在我们让前提条件平等起来，假设：

框架1，本身使用AOP方式进行IOC的注入（需在配置文件中指明依赖关系以及注入点），xiecc同志所做的工作由框架完成

框架2，就是yan了，使用injector 注入。

yan的injector注入优势在哪里？

为什么这么说呢？

现在讨论分两个部分：
1。这种充血设计到底好不好。（我的结论：鉴于它带来的依赖注入上的麻烦，它不见得就好）
2。抛开这种设计好不好先。如果面对这种充血设计，怎样能够最优雅地注射依赖。

对2，我确实同意spring失职，才搞得xiecc同学为了利用容器的功能，被迫使用aop，被迫采用service locator。

而yan在这方面就没有这个缺陷。它能够让你在坚持纯粹的ioc设计思路，不引入对aop和容器api的直接依赖的前提下仍然能够利用容器的力量。

你说的那个假想的框架1，是准备怎么处理程序中new DomainObject()的问题呢？是否也是要用aop硬生生插入依赖？
我是反对这种做法的，因为它让程序代码本身不能直接反映逻辑。这个天外飞来的aspect必须被每个读代码的人理解和知道才行。所以我才给出了一种不依赖aop，完全用oo的传统方法注射依赖的解决方案。

当然，具体项目如何抉择还是设计者的事情。yan本身其实也并非排斥aop，如果aspectj的aspect也能象普通class那样用ioc设计，比如：

aspect DomainAspect{
  Injector injector;
  ...
    injector.inject(obj);;
  ...
}

那么yan就可以利用aop来达到你要的这个效果。aspect不主动依赖容器，容器负责给aspect注射依赖。


这么说吧：只要你能通过java代码手工组装的，ioc容器都可以实现对这个组装的动态配置和集中管理。


至于injector，这是容器提供的一个可能性而已。你还可以用factory+proxy啊。

具体用哪种设计，这不是容器决定的，而是你自己分析需求的时候的选择，你甚至可以再发明一种新的方案。那种最符合需要就用哪种。容器只是提供基础设施罢了。

仍然不贴切呀。
c++对很多c不方便处理的问题给出了简单的解决方案。这些方案不光是写着简单，也方便阅读和维护。aspect就不同，写着简单了，维护却麻烦了。所以很多人说它是时髦的goto。要比喻，也是goto vs. continue/break更贴切一些。你说如果现在我推出一个superjava支持goto是进步还是退步呢？


至于说不相容，简单理解就是你能不能让aspect成为一个对象？我在java里面可不可以new some_aspect()？可不可以做一个aspect数组？可不可以给它们排序？函数可不可以用aspect做参数返回值？等等等等我对普通对象可以做的事情。

至于动态的原因？^_^，是不是给不出解决方法然后就想办法说这个目标本身是错误的？

原因可以很多呀。比如，乱想一个，要做一个测试控制台，测试员可以动态输入isolation level甚至测试程序自动在各种isolation level上跑。
或者，我想用容器来配置aspect的一些参数，但是不想让aspect主动依赖容器api，换句话说，我的aspect能不能也设计成dependency injection的？


aspect要解决的一个关键问题就在于如何和java code通信，要是能从java直接调用aspect，那就爽了。比如：

void f(int level);{
  Aspect aspect = new TransactionAspect(level);;
  Pointcut cut = new PointCut(...);;
  aspect.run(cut, new Runable();{
    public void run();{
      ...//被这个函数调用的代码都被那个aspect影响。
     //出了这个函数aspect就失效。
    }
  });;
}

这样，如果我想让某几个aspect在整个程序运行期间都有效，自然可以静态编译。而如果我需要动态灵活性，则可以在程序之中用代码来控制aspect。美好阿！

好吧.
现在项目要求,某一个some_operation_on_bank函数里面还需要自动注射BankAccount.bankid。
比如：

SomeBankService{
  private final BankAccountFactory factory;
  ...
  some_operation_on_bank(final int bank_id);{
    BankAccountFactory newfactory = new BankAccountFactory();{
      public BankAccount create();{
        BankAccount acc = factory.create();;
        acc.setBankId(bank_id);;
        return acc;
      }
    }
    BankAccountService service = 
       new BankAccountService(newfactory);;
    ......
  }
}

我完全可以用decorator搞定。aspect怎么办？


不是猜。你不就是这么说的吗？“aspectJ我不认为是额外的东西”这句话不是这么理解？


你在说什么？为什么要给smtp service提供工厂？哪跟哪啊？
什么叫“没有IOC之前”？ioc什么时候没有过？你是说ioc框架吧？
那么举个例子show一下你会怎么设计吧。
我的观点，ioc并不因为ioc框架而生。有没有ioc框架，对象该怎么设计还是怎么设计，根本不应该有区别。




就算很多也没有意义。因为"new Domain()"和"factory.newDomain()"本来就是一样的复杂度，你节省了什么？少敲了几下键盘？
我是有一个factory和proxy，但是这两个东西都可以做一个通用的出来，可以对任意项目通用。各个项目只需要用就可以了。你得aspect能做个通用的库出来？


是"我认为"么？那么说我认为错了？那你给纠正一下嘛。免得大家被我误导，看见这个臃肿的“独立测试”害怕。
你还没说你怎么管理维护你得mock aspect呢。没有aspect，我完全可以在测试代码里写任意多的mock factory，不同的test case用不同的，甚至同一个test case里面也可以用不同的。比如：

Service1 s1 = new Service(factory1);;
Service s2 = new Service(factory2);;
Object r1 = run(s1);;
Object r2 = run(s2);;
assertEquals(r1, r2);;

而你的mock aspect是不是还要先编译，增强，织入阿，你能像上面的代码那样在一个test case里面织入两个aspect么？


哦。人都是有选择的忽略乐自己不想知道的事实的。我都讲的很清楚了，像你这么用aspect让代码缺乏基本的因果关系。一般人读BankAccountService的代码会比较费解“bug! 这个构造函数里面没有设置smtpService，而这句new乐之后就直接用到了！”
这不是证据？当然，“维护性”没有完全客观的评判标准，你非说它理解容易，不会造成误解，可维护，我也无话可说。

至于是不是“乱用”才导致问题，还是先天性就破坏维护性，我们就不要争辩了。我完全相信有一些对goto的用法也不会造成面条代码。如果有goto的拥趸跟我争论goto不是先天性问题，而是用的不好才产生问题，我也无法可讲。


那。听好了：
[list]我想要让smtpService这个property optional，就是如果容器内没有就不注射。

我想让webServcice这个property有一个缺省值。

我想让session1和session2所用的bean都是prototype的。但是我要让session1和session2这两个property共享一个实例。

[/list:u]
别去改动aspect代码。我要的是可配置。

赫赫，你咋只字不提C++多出来的object感念呢？现在你不是也认为不含操作
的业务数据才是最佳的解决方案吗？
拿goto来比喻aspect更不贴切。
因为object不是面向关注点，而人的思维是面向关注点的，aspect正是在这种
境遇下提出来的。一个关注点跨越多个对象，一个对象包含多个关注点的部分。
这些才导致了OO的混乱。这方面的文章太多，在这里我就不详细阐述。

你说的不相容更是好笑，interface还不能直接new出来呢，你能说interface同
class不兼容吗？他们本来就是不同的概念，有不同的用法。

别乱想，来真的，要知道你实现的yanContainer是为实际应用服务的。而不是
应用非得要使用你提供的动态。
你具体的例子中，能告述我测试员为啥要动态的输入isolation level？测试
不同的isolation level数据库的不同表现？
没法说出确实的用途，我只能认为你是在毫无目的的乱动。
aspect至少在目前情况下，还不能被injection。但你这个需求是否合理呢?
aspect的实例目前还不能显示的实例化。也就不存在injection的问题。

从你下面的例子，说明你没有理解aspect的意图。aspect基本上是关注点的对应
你这样写，不是有把关注点分散到对象中去了吗？

别说你没在实际项目中运用过。换个名称就来玩我？
这种例子，令人费解，别满眼里都是注入阿。
目前我们针对外界服务的注入问题。
注入bankid?这..........就为了展示你的可decorator性？

我是指它是语言的一部分。

难道不是吗？我们讨论的不是如何注入非DomainObject的外界服务的问题吗？

俺还少了一个类阿。

说到你的通用性，你咋不提你这样一通用，开发人员要知道smtpService是如何
进来的，还得理解你的框架呢？确实“人都是有选择的忽略乐自己不想知道的事

实的”
aspect你都说了使用servicelocator，咋做不到通用？

你要说它臃肿我没买办法，但是通过mock aspect和real aspect共享父类。
没有你想象的那样肥。

通过归纳，我只能认为你喜欢毫无目的乱动。
不过我就跟着乱动一下好了，反正闲着也是闲着。
去看看aspectJ的关键字perthis,pertarget看看有没有解答你的问题。
另外我加问一句你的框架支持percflow吗？

你一直用OO的思想来理解AOP，就一辈子费解好了。AOP是OO的进化阿，老兄。

没关系阿，在domain中设上一些标志就是了，aspect来根据这些标志采取行动。
标志是可配置的。

aspect缺省就是单子，满足你的最后一个要求不难吧。