贫血就贫血,咂地?

这个俺有个粗糙的例子
http://www.iteye.com/viewtopic.php?t=13594

怎么获得服务 不用关心，可以横切。
和
  需要哪些服务  你需要关心。业务逻辑的一部分
，我说的是前面。

晕倒，要我看比较粗糙的例子， 你不会想累死我吧。 赫赫，等你修成正果了，我会拜读一份的。 赫赫 ，说笑而已，有空我会翻来看看的。 AOP我很关注它。

我啥时候说过引入新的概念不好了呢？我只是说这种新的概念在原来的语义模型里应该找到一个位置，而不是不兼容。用c的代码操作c++的对象是可以的，但是能不能用java的代码操作aspect呢？是个问题。老兄好像对这方面也不太了了嘛。看来大概是和面对的具体需求不相关的你就从来不去想？



具体。老兄，要具体，不要忽悠。:)


嗯。不错。问题差不多快解决了。最后一点就是，能否在java里面程序化地使用一个aspect，比如控制它和某个pointcut结合，控制它的织入点和有效范围？否则光能拿到aspect对象却不能使用不是个贫血aspect？:lol:



我也痛感这个缺陷。要不你来给一些实际的例子？至少目前，遇到的实际例子中（比如这个domain injection），spring处理不好的，yan都可以处理了。凭空想象一些大家都服气的例子可能不太容易，我那些例子更象hello world而不是实际的例子。但是，象hostler那样找出需求来看看yan能不能实现倒是可行的。
不过，如果从来都是只想框架能做的事情，不能做的都被剃刀剔除，只怕也很难发现什么想做而做不到的事情。
就象这个aop里面的service locator方法，hostler和xiecc就能感觉到不爽，只不过spring不支持更爽的方法。而你老兄却是甘之如饴，认为想要更灵活的想法是离经叛道，是么？


还是那句话，aspect的语义既然摆在那里了，如何用就是程序员的自由。不能用程序代码控制毫无疑问是个缺陷。（当然，也许你我不知道，aspect对象是可以由程序代码控制的呢？）

碰巧，我也有把剃刀。遇到那些复杂化了问题却不提供明显好处，同时明显地消弱了系统的灵活性的吃力不讨好的东西，我就毫不留情地剔除掉。直到我明确知道这种灵活性是肯定用不到的并且这些额外的复杂性可以有好的解决方案。
很不幸，在这个依赖注入的场合，aop就属于这个剃刀要剃掉的鸡肋。



请问你这里为什么需要一个工厂而不是直接的一个SmtpService？这个创建逻辑和你的send()有什么必要的联系？你那个smtpService的变量不放在局部而是全局又是什么意思？
如此胡乱设计，怪不得离不了aop这个拐杖。


是啊。我的意思是我喜欢我读到的代码本身就是完整的，正确的，而不是有一个bug等待aop来修复。


1。你的oo基础也不怎么样啊。怎么敢出来指责oo做不了aop的事情呢？
2。你的aop好像水平也马马虎虎啊，连aspect能注射都不知道，怎么敢就跳出来说aop是oo的进化呢？
3。你对我的框架也很不熟悉，怎么就敢指责了呢？
4。你对我说的那些灵活性本身并不了解，怎么就敢打包票不会用到呢？
5。你莫非是闻到臭鸡蛋也要吃的？
6。以上都是以其人之道，还治其人之身。实际上，我是觉得partech老兄辩论上了火气，开始口不择言了。这种没水平的口水仗，不打也罢。



你强。小孩我就管不了了。


果然强。这方法都能想的出来。我不知道为了用aspect是不是让你每天上下爬20层楼爬50遍你都愿意。:)



看，不理解吧？不理解前面就敢说“满足你的要求应该不难”？
r是从容器得到的domain object对象。
v是从容器得到的一个session对象。
session1, session2是这个domain object的两个类型为Session的property。

ajoo:
我啥时候说过引入新的概念不好了呢？我只是说这种新的概念在原来的语义模型里应该找到一个位置，而不是不兼容。用c的代码操作c++的对象是可以的，但是能不能用java的代码操作aspect呢？是个问题。老兄好像对这方面也不太了了嘛。看来大概是和面对的具体需求不相关的你就从来不去想？


partech:
咳...虽然我认为你这种要求没有啥子道理，但是aspect能够继承class可以实现接口，这算不算位置。
你说用c的代码操作C++的对象是啥含义？在C++只使用C的部分语法？不调用类的公用方法，而直接访问私有数据？嗯，这就是传说中的兼容了。
用java代码操作aspect又是什么含义？你老大概眼神不好，明明是个香蕉球，从你的位置看确是个直线球。
因为Aspect试图100%的兼容jVM,这样aspectJ就可以在任何的JVM上运行了，所以采用了一种织入的过程来，来将aspect变为普通的java类。
因此，它有一套不同于java类的规则，来管理aspect的生命周期。
对于织入后的java类，你确实可以向普通java类一样操作。如果希望操作织入前的aspect，现在只有gp了，如果java原生的支持emit和动态类型
你期望的并不是达不到。

俺从大学出来后,就没开发过正经的C++程序，咋被你看出来了勒？！惭愧啊，惭愧......

partech：
那你把OO面临的Tangling和Scattering的问题，用OO好好处理一下，如何？
ajoo:
具体。老兄，要具体，不要忽悠。

partech:
这你也认为是忽悠？斗啥子气哦。不就是没有关爱你那些可怜的例子吗？
你不想回答就算了。:) 反正你也没打算回答。


ajoo:
嗯。不错。问题差不多快解决了。最后一点就是，能否在java里面程序化地使用一个aspect，比如控制它和某个pointcut结合，控制它的织入点和有效范围？否则光能拿到aspect对象却不能使用不是个贫血aspect？

partech:
前面已经说明清楚，目前的实现方式，你的这种想法不现实。不过aspectJ里面好像有个去掉不能序列化编译错误的标志，具体干啥的不清楚。


ajoo:
我也痛感这个缺陷。要不你来给一些实际的例子？至少目前，遇到的实际例子中（比如这个domain injection），spring处理不好的，yan都可以处理了。凭空想象一些大家都服气的例子可能不太容易，我那些例子更象hello world而不是实际的例子。但是，象hostler那样找出需求来看看yan能不能实现倒是可行的。


partech:
一切付出总会有回报的，别着急哦。


ajoo：
还是那句话，aspect的语义既然摆在那里了，如何用就是程序员的自由。不能用程序代码控制毫无疑问是个缺陷。（当然，也许你我不知道，aspect对象是可以由程序代码控制的呢？）

老兄，目前恐怕不行哦。至少俺不知道。

ajoo:
碰巧，我也有把剃刀。遇到那些复杂化了问题却不提供明显好处，同时明显地消弱了系统的灵活性的吃力不讨好的东西，我就毫不留情地剔除掉。直到我明确知道这种灵活性是肯定用不到的并且这些额外的复杂性可以有好的解决方案。
很不幸，在这个依赖注入的场合，aop就属于这个剃刀要剃掉的鸡肋。


partech:
你剃你的，俺抱着你剔掉的aop，关键是有得玩啊，赫赫。:)


ajoo:
请问你这里为什么需要一个工厂而不是直接的一个SmtpService？这个创建逻辑和你的send()有什么必要的联系？你那个smtpService的变量不放在局部而是全局又是什么意思？
如此胡乱设计，怪不得离不了aop这个拐杖。

partech:
你说得俺头上直冒汗。
不直接传smtpService,是因为俺没得IOC用，只好自己动手create。
创建逻辑和send的关系，俺传了个this下去，可能this会影响create呢？谁知道。
不是局部变量是成员变量，因为俺怕其他方法还要用到勒。
您老给的需求实在太少，留给俺的想象空间太多。那个private肯定也有问题！


ajoo:
是啊。我的意思是我喜欢我读到的代码本身就是完整的，正确的，而不是有一个bug等待aop来修复。

partech:
对于可选的扩展，那就不叫作BUG。光看Eclipse中的IAdaptable也不完整阿。


ajoo:
1。你的oo基础也不怎么样啊。怎么敢出来指责oo做不了aop的事情呢？
2。你的aop好像水平也马马虎虎啊，连aspect能注射都不知道，怎么敢就跳出来说aop是oo的进化呢？
3。你对我的框架也很不熟悉，怎么就敢指责了呢？
4。你对我说的那些灵活性本身并不了解，怎么就敢打包票不会用到呢？
5。你莫非是闻到臭鸡蛋也要吃的？
6。以上都是以其人之道，还治其人之身。实际上，我是觉得partech老兄辩论上了火气，开始口不择言了。这种没水平的口水仗，不打也罢。


partech:
嗯，那俺好好消消火。

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

partech:
public class xxxDomainObject
{
private boolean usingSmtpService;
}


果然强。这方法都能想的出来。我不知道为了用aspect是不是让你每天上下爬20层楼爬50遍你都愿意。

partech:
又打哑谜。我们实际项目中，确实会用到外界的服务，比如和银行的接口和交易所的接口，不过你说是可选的调用，俺就糊涂了。

ajoo:
java代码:
Object v = ctxt.get("session");
r.setSession1(v);
r.setSession2(v);

看，不理解吧？不理解前面就敢说“满足你的要求应该不难”？
r是从容器得到的domain object对象。
v是从容器得到的一个session对象。
session1, session2是这个domain object的两个类型为Session的property。

partech:
俺不理解说明你没表达清楚。俺展望一下自己的能力也不可以了，多少艰难险阻都。。。。。咳咳。
还别说你的这些需求，确实比较怪异，没碰到过哟。
容我想想。

能不能继承不是关键。和java代码兼容的关键就是aspect能当正常的对象那样用。final class还不能继承呢，so what？



这种语言建模上的话题对你来说可能有点勉为其难了。怪不得你不懂。这样说吧，c里面有指针，可以指向任何数据，c里面有typedef可以对任何类型定义别名，sizeof()可以得到任何一个类型的大小，c里面期望任何变量都有地址，都能用"&"操作符。这些对“任何类型”的操作在c++里面仍然有效。
至于说sruct操作数据成员，c里面还不能操作int的成员呢，本来就不属于基本语义模型，自然无所谓。






呵呵。这就叫双重标准。让别人举例子，helloworld式的还不行，非得您老看着合适。
到自己这，不举例子，就随便抛出几个词就想过关？莫非是传说中的“心虚”？



你说的是能不能做到，我说的是我认为应该支持的功能，咱俩这点上不矛盾。何况你只怕也不清楚是否真不能做到，是否原理上不能做到，还是只是暂时不支持。

这个factory不是也是ioc注射进来的？为什么不直接ioc一个smtpservice进来？什么叫“没有ioc用”？ioc模式只要你想用就可以用，根本不依赖容器存在与否。


嗯。关键我看代码看不见有个“可选的扩展”啊。你得用大字在代码里注释：这里等待一个aop注入！！！！！！
那我也未必看得见。


我是说，在注入的依赖的时候，我也许会让某个property可选，而不是把这个逻辑硬编码到domain里面。


让这些东西可配置就是为了对付各种匪夷所思的古怪需求阿。

ajoo:
呵呵。这就叫双重标准。让别人举例子，helloworld式的还不行，非得您老看着合适。
到自己这，不举例子，就随便抛出几个词就想过关？莫非是传说中的“心虚”？


partech:
你激将我也没有，这个不在俺目前的研究范畴。
回头一定给你举个具体得不能再具体的例子，到时候，别发毛噢。嘿嘿

ajoo:
你说的是能不能做到，我说的是我认为应该支持的功能，咱俩这点上不矛盾。何况你只怕也不清楚是否真不能做到，是否原理上不能做到，还是只是暂时不支持。

partech:
不改jVM,没戏。

ajoo:
这个factory不是也是ioc注射进来的？为什么不直接ioc一个smtpservice进来？什么叫“没有ioc用”？ioc模式只要你想用就可以用，根本不依赖容器存在与否。


partech：
俺传递了个this下去，看见没？

ajoo:
嗯。关键我看代码看不见有个“可选的扩展”啊。你得用大字在代码里注释：这里等待一个ioc注入！
那我也未必看得见。

partech:
正因为是可选的扩展，那就可能使随着时间推移，才出现的，
以前本来就没有啊，不可预测的变更你如何预测？如何贴标签？
比如：股票交易原来是恒定收0.003的俑金，后来变为券商可以自行调整俑金，
预测不到的。
另外，ajdt明确的标明了切点等，相互的关联，还不够吗？

ajoo:
我是说，在注入的依赖的时候，我也许会让某个property可选，而不是把这个逻辑硬编码到domain里面。

partech:
别怪我说你怪异。你这里可选了，如果真实情况下是必须要调用的，不就糗了。
虽然你能配置，但这里配置就错了。


ajoo:
让这些东西可配置就是为了对付各种匪夷所思的古怪需求阿。

partech:
唉，每个变化都至少有个真实的需求，你把时间都花在这些匪夷所思的咚咚上，值得吗？