论坛首页 Java企业应用论坛

贫血就贫血,咂地?

浏览 54130 次
精华帖 (1) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
作者 正文
   发表时间:2005-11-03  
ajoo同志,这次偶支持侬。
等兄弟忙完了这一段,一定到这个帖子里面当打手,重新把它顶起来。
0 请登录后投票
   发表时间:2005-11-03  
charon 写道
ajoo同志,这次偶支持侬。
等兄弟忙完了这一段,一定到这个帖子里面当打手,重新把它顶起来。

Partech同志,这次偶支持侬。
等兄弟忙完了这一段,一定到这个帖子里面当打手,重新把它顶起来。

0 请登录后投票
   发表时间:2005-11-03  
ajoo 写道

[list]1。不可能。你怎么手工intercept深深隐藏在业务代码中的new BankAccount()?没有aspectj你搞得定吗?

2。看看xiecc的那片文章。他就是直接调用application context。这就是依赖。

3。完全是aspect想在这里干?你aspect得敢不想干啊。没有aspect代码就根本不工作。而我的设计不隐含着对任何框架的依赖。只要你给我传入合适的factory,我就可以工作。这个factory你完全可以手工创建。这里我要的是injection,不是interception。injetion任何时候都可以mock,interception不可以。

4。new vs. factory的优势我解释过了,有,但是非常有限。如果你认为“能够用new”是压倒一切的目标的话,那自然万事皆休。其实,在这个目标下,所有ioc设计都是垃圾。应该直接new才是正理。[/list:u]

1.确实AOP对于你来说,开始不可思议了 。普通对象有mock,aspect就不能有了吗?我可以简单的写个mock aspect和mockService来模拟实际的服务。
2.3.aspect里依赖于其他东西,当然是允许的。这里的aspect等价于你的组装程序,而不是Domain。同样道理你的方案,domain离开了框架同样得不到注入。
4.这么说来,你domain里面的factory就隐含的依赖某个IOC框架罗。
0 请登录后投票
   发表时间:2005-11-03  
ajoo 写道
partech 写道
如图虽然不是存款,含义一样。


你这个例子,从图上就可以看出,room, reservation, bill是三件各自可以独立的事情。任何一件事都不依赖另外两件事就可以成为一个逻辑上完整的动作。aop只不过用来把三件事情穿起来而已。虽然这种东西用传统的oo的封装就可以做,用aop倒也不算多么滥用。


但是这个domain object injection却不同。aspect里面做的事情和domain里面的逻辑密切相关,没有aspect,domain里面的逻辑根本就不完整。这种东西和这个例子却是本质上就不同。

我相信,任何aop能做到的东西,在现有环境内都可以找到变通的做法。但是正如你一直追求的“优雅”一样,我也会问,“哪一个更优雅呢?”

具体到这个inject的问题,aspect等价于你的注入程序,而不是domain。domain仅仅依赖外界服务的接口。
0 请登录后投票
   发表时间:2005-11-03  
partech 写道

1.确实AOP对于你来说,开始不可思议了 。普通对象有mock,aspect就不能有了吗?我可以简单的写个mock aspect和mockService来模拟实际的服务。
2.3.aspect里依赖于其他东西,当然是允许的。这里的aspect等价于你的组装程序,而不是Domain。同样道理你的方案,domain离开了框架同样得不到注入。
4.这么说来,你domain里面的factory就隐含的依赖某个IOC框架罗。


1. 这么说你承认你的单元测试非得带着aspect一块儿测才行了,对么?这个“单元测试”好象和普通意义有了那么点不同。你倒不嫌麻烦了? 
我承认我有点惊讶,真是没想到有人会去mock aspect。也不知道你的自动测试程序中会不会有一堆mock aspect给各个不同的test case用。可以给大家分享一下经验你怎么维护这么多的mock aspect的么?
对了, 其实,aspect还有其它的麻烦的。比如说,aspect的编写完全是静态的,而如果是注射我可以在程序的任意地方动态时候切换:
if(user input =="a");
  new BankService(new AFactory(););;
else if(user input=="b");
  new BankService(new BFactory(););;
...

也可以任意地增加decorator,proxy什么的。比如:
x = ...;
factory = ...;
new BankService(new SomeDecorator(factory, x););;

当然,这种灵活的用法可能对你是不可思议的了。

2。错。它并不等价于我的组装代码。你的spring配置文件才等价于组装代码。而你的aop是用来把spring和domain粘在一起的另一层东西,即使你不把它归类为domain,它也是额外的一个层次。在我的方案里不需要这一层东西。
更何况,在你的aspect里面,对哪些属性注射,是不是有些属性是optional,有没有default value之类的策略都是硬编码而不能配置。在我的方案里面则不是(当然,是指使用一个xml或者脚本的外壳的情况)。

partech 写道

同样道理你的方案,domain离开了框架同样得不到注入。


这么说来,你domain里面的factory就隐含的依赖某个IOC框架罗。


看来,我只能理解为你不懂ioc模式了。去年我就在喊ioc不是ioc容器,没想到还是有人有这种错误观念。一个ioc设计的对象依赖于ioc框架么?这种代码不费解吧?
new BankService(new SomeFactory(););;

不知道它依赖于哪家的框架了?没有框架得不到注入?什么逻辑?
0 请登录后投票
   发表时间:2005-11-03  
partech 写道

我相信,任何aop能做到的东西,在现有环境内都可以找到变通的做法。但是正如你一直追求的“优雅”一样,我也会问,“哪一个更优雅呢?”

具体到这个inject的问题,aspect等价于你的注入程序,而不是domain。domain仅仅依赖外界服务的接口。


当然是注射比拦截优雅了。注射仅仅使用oo,而不引入额外的aspect。而且注射可以在程序任何地方动态调整,注射进入的对象可以携带程序运行的局部状态。比如:
int x = read integer from file;
new BankAccountService(new FactoryA(x););;


而aspect是静态的,有太多的限制。

在加上aspect影响程序可理解性,可维护性,不利于单元测试。真不知道它什么地方“优雅”。
0 请登录后投票
   发表时间:2005-11-03  
aspect的最大问题在我看来就是可以乱划辅助线,可以划的让你完全找不到北,不知道设计到底是如何运作的,简单来说就是可以轻易制造大混乱的根源。当然,我们不否认部分划线高手可以行云流水般操纵自如,但是正如OO逐步舍弃同样可以轻易制造大混乱的多重继承一样,在克服其缺点之前aspect相信也难以成为主流。
0 请登录后投票
   发表时间:2005-11-03  
ajoo 写道

1. 这么说你承认你的单元测试非得带着aspect一块儿测才行了,对么?这个“单元测试”好象和普通意义有了那么点不同。你倒不嫌麻烦了? 
也不知道你的测试程序中会不会有一堆mock aspect给各个不同的test case用。可以给大家分享一下经验你怎么维护这么多的mock aspect的么?
对了, 其实,aspect还有其它的麻烦的。比如说,aspect的编写完全是静态的,而如果是注射我可以在程序的任意地方动态时候切换:
if(user input =="a");
  new BankService(new AFactory(););;
else if(user input=="b");
  new BankService(new BFactory(););;
...

也可以任意地增加decorator,proxy什么的。比如:
x = ...;
factory = ...;
new BankService(new SomeDecorator(factory, x););;

当然,这种灵活的用法可能对你是不可思议的了。

2。错。它并不等价于我的组装代码。你的spring配置文件才等价于组装代码。而你的aop是用来把spring和domain粘在一起的另一层东西,即使你不把它归类为domain,它也是额外的一个层次。在我的方案里不需要这一层东西。


引用

同样道理你的方案,domain离开了框架同样得不到注入。

这么说来,你domain里面的factory就隐含的依赖某个IOC框架罗。


看来,我只能理解为你不懂ioc模式了。一个ioc设计的对象依赖于ioc框架么?这种代码不费解吧?
new BankService(new SomeFactory(););;

不知道它依赖于哪家的框架了?没有框架得不到注入?什么逻辑?

1.赫赫是的,我的单元测试就是要依赖aspectJ。因为在我看来aspectJ,完全可以作为语言的一部分。
我是在测试domain类,不是别的,而且我也能够测试。维护不是问题因为aspect也是一种class。
你所说的灵活性,也完全适用于AOP,你代码中的灵活性,完全跟讨论的主题正交。mock aspect中同样可以这样写。
2.前面已经说明,aspectJ我不认为是额外的东西,能够确认它不是domain就行了。
3.要弄清你使用factory的原因是什么。不是为了你后面能够否注入吗?
无论依赖于那家框架,这种设计是在有IOC的框架前提下出来的。

无论如何,AOP在单点维护上确实是站有优势。并且也能实现独立的单元测试。理解的问题,太个人化了,我认为理想,你认为“怪异”。
0 请登录后投票
   发表时间:2005-11-03  
ajoo 写道

当然是注射比拦截优雅了。注射仅仅使用oo,而不引入额外的aspect。而且注射可以在程序任何地方动态调整,注射进入的对象可以携带程序运行的局部状态。比如:
int x = read integer from file;
new BankAccountService(new FactoryA(x););;


而aspect是静态的,有太多的限制。

在加上aspect影响程序可理解性,可维护性,不利于单元测试。真不知道它什么地方“优雅”。

你不如说汇编比OO优雅,因为它最直接的对应机器代码,很清晰。不会额外的引入object的概念。
我不太理解,你说的aspect是静态的,是指什么?
0 请登录后投票
   发表时间:2005-11-03  
age0 写道
aspect的最大问题在我看来就是可以乱划辅助线,可以划的让你完全找不到北,不知道设计到底是如何运作的,简单来说就是可以轻易制造大混乱的根源。当然,我们不否认部分划线高手可以行云流水般操纵自如,但是正如OO逐步舍弃同样可以轻易制造大混乱的多重继承一样,在克服其缺点之前aspect相信也难以成为主流。

刺梨扎人,但我还是喜欢吃。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics