贫血就贫血,咂地?

c++的对象模型和c的指针拉什么不冲突阿。c里面的结构，指针可以当作函数参数返回值，c++增加的对象一样可以。可以说c++增加的这个对象对c原来的模型是完全兼容的。
这跟aspect可不同。如果纯java代码不能调用aspect，则说不上兼容。


这些文章多数是自说自话, 拿一个蹩脚的oo设计和所谓的ao比较。aspect确实是根据关注点提出的。但是ao并没有证明oo对这些东西就不能很好的处理。也没有提供很好的解决ao导致的维护困难的方法。也许aop是一个饮鸩止渴的方法呢？



好吧。那个new的说法欠妥。我实际的意思是在java里面能够实例化一个aspect对象，管你是new，还是工厂还是什么？
而且，java里面，所有对象都可以放进collection，不知道aspect能么？
是，很多东西都有不同的概念，不同的方法。但是，归根结底，它们的基本语义模型都是Object。它们都可以被当作函数的参数和返回值，这是一个编程语言的根本。如果这都不可以，那么基本上只能算作两个互不相容的体系了。


老兄。反正例子我也举了。你不满意，我也无法可想。就算isolation level你认为没意义，举一反三一下都不能？
我倒也没有太多兴趣帮你想这些例子。我承认这点我不能说服你，但是你知道有这么个“灵活性”的事就够了。你说“乱动”就乱动罢。没必要统一思想。




等等。刚看了xiecc那片文章，他的aspect就是有injection的呀。我还在想：这下糗了。:)


我倒是觉得你没有理解我的意图。一个aspect其实起的作用就是拦截。这就够了。没有可能需要在程序里面做拦截么？你这个结论下的太武断了。程序的需求千变万化，我不认为什么逻辑可以保证绝对不会需要用程序来控制，即使是aspect。
不能就是不能，没必要酸葡萄吧？

我确实不善于举例子。不过我发现你特别善于挑我的例子举的恰当与否。从那个smtpService开始，就开始对我可怜的例子们大加刁难，似乎不举一个完全符合你心意的例子就讨论不下去似的。既然你这么不会举一反三，我就放弃了。
结论可以这样下：
aspect不能提供某些灵活性，但是这些灵活性据partech老兄鉴定不具有实际意义。
这可以了吧？



这段恢复有点让我看不懂啊。是针对我的哪句话呢？是不是那个如果没有ioc框架你会如何设计呀？对了，你还没给我介绍你的设计方案呢。


这就有点抬杠了吧？用我的设计，你如果不想知道，一样可以忽略呀。如果想知道，至少这个factory可以让程序员知道肯定是factory设置的，完全符合正常人的因果关系的思维逻辑。
用aop呢。你要是想知道可就麻烦了。代码本身单独来看属于有bug的，是通过aop才把这个bug修上。



看看那篇我对xiecc方法的批评
http://forum.iteye.com/viewtopic.php?t=16667&start=45
那个aspect怎么可能做到通用？


不好意思。一直对aspect不敢冒，这些细节都不懂。你介意解释一下吗？
我的框架不是aop框架，是ioc。


我总觉得aop这个名称非常夸大其词。它根本不能像oo，甚至我总结的functional programming里面的co那样，提供完整的解决方案和建模模型，而只能寄生在OO上。
但是这种寄生，又不能和原生语言良好结合，这就会造成很大的问题。
而aop的那些明显的毛病在我看来并不费解呀，再明显不过了。不管这o，那o，不符合基本的因果规律，乱画辅助线，就是大毛病，用什么思想来理解都是这个结论。我看到是你拿了个aop的锤子看什么都是钉子了。:lol:



给出具体解决方案来？仔细想想你就会发现问题多多了。



差远了。注意，我说的是，session1, session2这两个组件都是prototype，也就是说，每次向容器申请，都会得到一个新的实例。
但是，我要求每次只申请一次，然后把得到的这个值交给session1, session2两个property。这样：

Object v = ctxt.get("session");;
r.setSession1(v);;
r.setSession2(v);;

呵呵， 是不是又要批评我“乱动”乐？

ajoo:
c++的对象模型和c的指针拉什么不冲突阿。c里面的结构，指针可以当作函数参数返回值，c++增加的对象一样可以。可以说c++增加的这个对象对c原来的模型是完全兼容的。
这跟aspect可不同。如果纯java代码不能调用aspect，则说不上兼容。

partech：
是哦，C++和C的指针不冲突哦，不过数据为啥要同处理它的函数绑在一起呢？这明显是对数据和函数的非法约束嘛，干嘛要引入这种封装的概念，是谁说这种封装就好的。。。。[以下省略500字]。


ajoo:
这些文章多数是自说自话, 拿一个蹩脚的oo设计和所谓的ao比较。aspect确实是根据关注点提出的。但是ao并没有证明oo对这些东西就不能很好的处理。也没有提供很好的解决ao导致的维护困难的方法。也许aop是一个饮鸩止渴的方法呢？

partech：
那你把OO面临的Tangling和Scattering的问题，用OO好好处理一下，如何？


ajoo:
好吧。那个new的说法欠妥。我实际的意思是在java里面能够实例化一个aspect对象，管你是new，还是工厂还是什么？
而且，java里面，所有对象都可以放进collection，不知道aspect能么？
是，很多东西都有不同的概念，不同的方法。但是，归根结底，它们的基本语义模型都是Object。它们都可以被当作函数的参数和返回值，这是一个编程语言的根本。如果这都不可以，那么基本上只能算作两个互不相容的体系了。

partech：
aspect可以继承class，它当然能放到集合里面，目前它只是不能在程序里new出来而已。
代码如下：
public class C1
{

}

public aspect TestAspect1 {
    pointcut create() :call(*.new(..));
    after() returning(Object o): create()
    {
    }
    public String toString()
    {
        return "me";
    }
}
public class TestC
{
           public static void main(String[] args)
           {
               C1 c1 =
                   new C1();
                 boolean hasAspect =
                  TestAspect1.hasAspect();

                 TestAspect1[] testAspects = new TestAspect1[4];
                 testAspects[0] = TestAspect1.aspectOf();
                 testAspects[1] = TestAspect1.aspectOf();
                 System.out.println(testAspects[0]);
                 System.out.println(testAspects[1]);
           }
}
是不是有人也会糗呢？:)

ajoo:
老兄。反正例子我也举了。你不满意，我也无法可想。就算isolation level你认为没意义，举一反三一下都不能？
我倒也没有太多兴趣帮你想这些例子。我承认这点我不能说服你，但是你知道有这么个“灵活性”的事就够了。你说“乱动”就乱动罢。没必要统一思想。


partech：
老兄没在真实的项目里玩过，就别如此强烈的推荐的框架如何如何的好。如果你用过我相信举个实际的例子应该不难。
是的，说句中肯的话，如果你想你的框架得到推广，还真得弄些实际一些的例子，目前类似的框架如此众多，你不贴近一点应用，叫开发人员如何能喜欢起你的框架来？

ajoo:
刚看了xiecc那片文章，他的aspect就是有injection的呀。我还在想：这下糗了。

partech:
tbd

ajoo:
我倒是觉得你没有理解我的意图。一个aspect其实起的作用就是拦截。这就够了。没有可能需要在程序里面做拦截么？你这个结论下的太武断了。程序的需求千变万化，我不认为什么逻辑可以保证绝对不会需要用程序来控制，即使是aspect。
不能就是不能，没必要酸葡萄吧？

partech:
拦截只是aspect的一种表现形式，aspect的作用远远不止于此。
你想在class里面看到aspect的声明，可以使用Inner Aspects。

看起来好象是在说OO永远都是面临Tangling和Scattering问题，并且OO机制无法解决这些问题，所以今天发现一个问题就去打个AOP补丁，明天发现另一个问题又去打一个补丁。但是实际经验告诉我们，只要积累了足够多的实践经验，最终总是能够精炼出高度抽象、泛用及稳健的OO模型，这时候你怎么办？继续维持这种半调子OO模型加AOP补丁的状况？

Partech 的打手来了：

Ajoo 说：
你说的那个假想的框架1，是准备怎么处理程序中new DomainObject()的问题呢？是否也是要用aop硬生生插入依赖？
我是反对这种做法的，因为它让程序代码本身不能直接反映逻辑。这个天外飞来的aspect必须被每个读代码的人理解和知道才行。所以我才给出了一种不依赖aop，完全用oo的传统方法注射依赖的解决方案。
因为它让程序代码本身不能直接反映逻辑 ，这句话我不是很赞同，从程序来看，这个逻辑已经很明确，就是需要依赖于一些组件。
至于怎么获取这些组件，程序本身的逻辑可以不管，这也是现在IOC以致提倡的。
我的理解是，不管是天外飞来也好，地下爬出也好，能够让用户越透明使用的就越好，不用用户必须显式的经过某些步骤来得到组装。
然而，为了达到这个目标，如今真的没有好的工具，除了AOP，AOP如果真的能够达到这种他所说的这种效果，就算项目引入打它的依赖，我还是很乐意的。 但是听说，现在的AOP产品都得对CLass进行bytecode 的 enhancer，这点是很值得斟酌的。 我更喜欢那些Runtime 的基于拦截器的AOP实现。 但是，无论那些，真的希望达到 无缝，透明的组装。 这点希望不是理想主义。

AOP不能滥用的，其实，正如你所说的一样，使用AOp有一个前提原则，能够OO的就不要考虑AOP。
AOP一般用在能够正交的横切面上，比如上面一直讨论的Service的IOC问题。
这个跟业务逻辑没什么瓜葛，仅仅是注入Service组件而已，我觉得如果AOP能够实现这点，我是很乐意来引入它实现ajoo所说的充血模型的。

你这样说不是在忽悠我吧？！也罢，等你“最终总是能够精炼出高度抽象、泛用及稳健的OO模型”的时候，咱们在讨论吧。

能够OO的就不要AOP。
AOP还是有其一定的适用范围的。这点AOP之父再一篇文章具体说过这个问题，具体连接我忘记了。

ajoo:
我确实不善于举例子。不过我发现你特别善于挑我的例子举的恰当与否。从那个smtpService开始，就开始对我可怜的例子们大加刁难，似乎不举一个完全符合你心意的例子就讨论不下去似的。既然你这么不会举一反三，我就放弃了。
结论可以这样下：
aspect不能提供某些灵活性，但是这些灵活性据partech老兄鉴定不具有实际意义。
这可以了吧？

partech:
当然了，剃刀时刻在我手里拿着呢，本人精力有限，实在没时间讨论你幻想的场景，因为是你幻想的，当然没个客观的标准。
不用举一返三，就一个实际的应用场景就行了，仅仅需要一个。
结论应该如此：
yan具有高度的灵活性，但目前没有实际运用的场景，aspect不对这种场景进行假设，aspect目前不提供yan那样的高度灵活，直到这种需求真的出现为止。


ajoo:
这段恢复有点让我看不懂啊。是针对我的哪句话呢？是不是那个如果没有ioc框架你会如何设计呀？对了，你还没给我介绍你的设计方案呢。

partech:
满足你的好奇心理把
public class BankAccount
{
    SmtpService smtpService;
    SmtpServiceFactory smtpServiceFactory; 

    public setSmtpServiceFactory(SmtpServiceFactory smtpServiceFactory)
     {
       this.smtpServiceFactory = smtpServiceFactory;
     }   

    private void send()
    {
      smtpService = smtpServiceFactory.Create(this);
      smtpService.send(getAccountInfo());
    }
}
注意这里是对smtpService使用工厂，而不是BankAccount。


ajoo:
这就有点抬杠了吧？用我的设计，你如果不想知道，一样可以忽略呀。如果想知道，至少这个factory可以让程序员知道肯定是factory设置的，完全符合正常人的因果关系的思维逻辑。
用aop呢。你要是想知道可就麻烦了。代码本身单独来看属于有bug的，是通过aop才把这个bug修上。


partech:
是哦，AOP的用处之一就是可以修复某些BUG。但你说他都属于修复BUG，就不对了。

ajoo:
看看那篇我对xiecc方法的批评
http://forum.iteye.com/viewtopic.php?t=16667&start=45
那个aspect怎么可能做到通用？

partech:
这个问题，还有前面的那个，俺要确认下，才能答复。

ajoo:
不好意思。一直对aspect不敢冒，这些细节都不懂。你介意解释一下吗？
我的框架不是aop框架，是ioc。

partech:
不对aspect有个完整的了解，就站出来指责，也真有你的。
莫非你也和李敖大师一样？“臭鸡蛋闻闻味道就是了，还打算吃它吗？”

ajoo:
我总觉得aop这个名称非常夸大其词。它根本不能像oo，甚至我总结的functional programming里面的co那样，提供完整的解决方案和建模模型，而只能寄生在OO上。
但是这种寄生，又不能和原生语言良好结合，这就会造成很大的问题。
而aop的那些明显的毛病在我看来并不费解呀，再明显不过了。不管这o，那o，不符合基本的因果规律，乱画辅助线，就是大毛病，用什么思想来理解都是这个结论。我看到是你拿了个aop的锤子看什么都是钉子了。

partech:
是的，小孩拿了个剪刀，什么东西都敢剪，咋了？！

ajoo:
给出具体解决方案来？仔细想想你就会发现问题多多了。

partech:
public class xxxDomainObject
{
  private boolean usingSmtpService;
}


ajoo:
差远了。注意，我说的是，session1, session2这两个组件都是prototype，也就是说，每次向容器申请，都会得到一个新的实例。
但是，我要求每次只申请一次，然后把得到的这个值交给session1, session2两个property。这样：
java代码: 

Object v = ctxt.get("session");
r.setSession1(v);
r.setSession2(v);
呵呵， 是不是又要批评我“乱动”乐？

partech:
小朋友不乖可以理解。:)
你这里的v是啥？r是啥？session1,session2在哪里啊？

service 的注入是 业务逻辑？ 横切面？

例子1
如果当前用户是本公司用户， 使用msn发送消息，
如果当前用户不是本公司用户， 使用mail发送消息，

那么这个MsgSender 的注入是业务逻辑？ 横切面？

就是 XXXDao 的注入，也不完全是横切面，也可能夹杂着业务逻辑
例子2
如果当前用户是VIP用户， 使用数据库1
如果当前用户不是VIP用户， 使用数据库2