贫血就贫血,咂地?

看到了吧。某些人自己举具体的例子也发毛。:)



吓！这样的SmtpServiceFactory？

intervace SmtpServiceFactory{
  SmtpService create(BankAccount acct);;
}

怪异亚。为什么这么搞？循环依赖都搞出来了？是不是每个用到smtp的domain类型都有一个自己的SmtpServiceFactory？



这个标明在哪里？在domain的代码里还是你得aspect里？


你不会配置那些本身就可选的property？你要是硬给要苹果的注射鸭梨还也完蛋了呢。


兄弟，做框架和你做应用不同的。我不能随意假设某个需求不合理。就象某些人会认为给domain object注射依赖不合理，我也认为用aop来注射依赖是个坏想法，但是，框架本身还是要尽量兼容各种设计。
我不是说做框架就是要大而全。每次想到一个新功能都修改框架绝对不好。shopping list似的系统应该避免。但是我的框架因为有一个灵活的内核，可以支持任何直接用java代码可以做到的功能，所以扩展起来顺手支持这些古怪或者不古怪的功能倒也不费什么时间，还省得我费神去想“什么功能不合理，不用支持"之类的。只不过，想一个让你满意的实际例子倒是挺费时间的。

ajoo:
怪异亚。为什么这么搞？循环依赖都搞出来了？是不是每个用到smtp的domain类型都有一个自己的SmtpServiceFactory？

partech:
怪异麽？就这个例子来说，你要认为是循环依赖也没什么不可以。不过为了灵活接口可能这样，
interface SmtpServiceFactory{
  SmtpService create(Account account);
}
不同的Account可以有不同的SmtpService，不管怎样，获取smtpService需要依据Account中的状态来决定。
这不是过分的需求吧？你老见多识广，不该惊讶哦。

ajoo:
这个标明在哪里？在domain的代码里还是你得aspect里？

partech:
Eclipse中的aspectJ开发环境ajdt阿，里面明确的标明了切点和织入点，以及类的横切图。

ajoo:
我是说，在注入的依赖的时候，我也许会让某个property可选，而不是把这个逻辑硬编码到domain里面。
partech:
别怪我说你怪异。你这里可选了，如果真实情况下是必须要调用的，不就糗了。
虽然你能配置，但这里配置就错了。
ajoo:
你不会配置那些本身就可选的property？你要是硬给要苹果的注射鸭梨还也完蛋了呢。

partech:
赫赫，该不该调用Service，什么时候调用，该是DomainObject知道。
注入的职责应与上面无关，所以注入者，无论service是否被调用，什么时候被调用都不该知道。
或许为了lazyload可以考虑注入一个proxy,但是没有什么可选注入的说法。注入是必定的。
不是我会不会配置的问题，注入者根本就不该有判断是否是可选注入的能力。

ajoo:
.......

partech:
继续你前面的有关DomainObject使用两个Session的讨论。需要你确认以下几点：
这里的Session是否是ThreadLocal的？
Session是有状态的麽？

我没看错吧，同样一个DomainObject调用不同的方法注入同样一个Session对象？
至少你写的代码要符合你需求的意图吧？！

用你的话。这实际么？有什么实际需求要这样？一个循环依赖就是坏味道。我对稀奇古怪的需求没什么反感，但是对需要写坏味道的代码的需求还是很挑剔的。你得给出真正有道理必须这么做的理由，
当然，即使有这么做的理由，又如何？这仍然是个ioc设计。你能拿它说明什么？


应该说这是有帮助得，可以一定程度上缓解aspectj对可读性的破坏。只不过，我对“代码自说明”很有一种宗教式的信仰，要依赖某些ide才看得懂的代码，嗯，总要给我足够的好处我才会这么干。


好像你的一贯办法就是说：这个功能不应该有！
好个釜底抽薪。也真够自信的。你觉得你自己的那点经验就足以代表所有人所有情况？就敢这么武断？
一个ioc模块每个需要注入的组件的具体语义都是明确的，组装者当然需要知道每个组件是怎么回事，需要以什么方式注入最合适。可选与否，是否有缺省值都是这个语义的一部分。



还是老一套。说不出来就拿需求本身说事。
你说说你什么好呢？自己做不到就说做不到好啦。
总找借口，鄙视你一下先。

这种东西完全可能。每个需要ioc的组件配件都有自己的语义。只要组装者能够确定某个instance同时满足两个语义就可以。反向控制本来就是说把控制权让给组装者。什么都由组件自己决定，那叫什么ioc？

ioc的本意，就是组件明确提出需求，等待外界注入。
组装者根据组件的需求和自己手里的供货情况，提供合适的实现给组件。
这就是一个简单的需求与供给。只要组装者知道自己的某个实例足以实现两个或者更多的需求，自然可以用这一个实例来给多个依赖注射。

说穿了，你还是不懂ioc这个设计，而只是把spring什么的作为一个配置工具。小孩子使大铁锤，难免要出些洋相。


再比如：你有setXXX(XXX xxx), setYYY(YYY yyy)两个setter. XXX, YYY是两个接口。而组装者手里正好有一个类XXXYYYImpl同时实现了XXX和YYY，当然就可以选择用一个实例给两个属性注射。这有什么大惊小怪的？

ajoo:
用你的话。这实际么？有什么实际需求要这样？一个循环依赖就是坏味道。我对稀奇古怪的需求没什么反感，但是对需要写坏味道的代码的需求还是很挑剔的。你得给出

真正有道理必须这么做的理由，
当然，即使有这么做的理由，又如何？这仍然是个ioc设计。你能拿它说明什么？

partech:
这里你开始讲起真实的需求？这当然实际，不同的BankAccount可能对应不同的接口，同一个银行还有好几种帐户区别，不同的帐户可能会分属不同的系统，这意味着不

同的服务。相互依赖就一定是坏味道了？赫，也鄙视你一下。Object还和String相互依赖了勒。
不如何，我是对外界服务提供工厂，而不是Domain对象本身，这就够了。你可以继续忽悠......

ajoo:
应该说这是有帮助得，可以一定程度上缓解aspectj对可读性的破坏。只不过，我对“代码自说明”很有一种宗教式的信仰，要依赖某些ide才看得懂的代码，嗯，总要给

我足够的好处我才会这么干。

partech:
首先你认为对于语言的任何革命都该是必须遵守你认为的某种规则，这很荒唐。C++之于C是一种演化的方式，但不等于说，今后OO的演化方式就要和以前的一样满足同样

的规则。我相信你也不具有这种能力......

ajoo:
好像你的一贯办法就是说：这个功能不应该有！
好个釜底抽薪。也真够自信的。你觉得你自己的那点经验就足以代表所有人所有情况？就敢这么武断？
一个ioc模块每个需要注入的组件的具体语义都是明确的，组装者当然需要知道每个组件是怎么回事，需要以什么方式注入最合适。可选与否，是否有缺省值都是这个语

义的一部分。

partech:
我这点经验代不代表所有人的情况并不重要，至少代表我自己。
不知道你所说的当然是如何得到的？仙人托梦？很简单，就我上面的例子，domain对象依赖内部状态有条件的决定是否调用外界可选服务，你用你的组装者来展示一下如

何？

ajoo:
这种东西完全可能。每个需要ioc的组件配件都有自己的语义。只要组装者能够确定某个instance同时满足两个语义就可以。反向控制本来就是说把控制权让给组装者。

什么都由组件自己决定，那叫什么ioc？
ioc的本意，就是组件明确提出需求，等待外界注入。
组装者根据组件的需求和自己手里的供货情况，提供合适的实现给组件。
这就是一个简单的需求与供给。只要组装者知道自己的某个实例足以实现两个或者更多的需求，自然可以用这一个实例来给多个依赖注射。

说穿了，你还是不懂ioc这个设计，而只是把spring什么的作为一个配置工具。小孩子使大铁锤，难免要出些洋相。


再比如：你有setXXX(XXX xxx), setYYY(YYY yyy)两个setter. XXX, YYY是两个接口。而组装者手里正好有一个类XXXYYYImpl同时实现了XXX和YYY，当然就可以选择用一

个实例给两个属性注射。这有什么大惊小怪的？

partech:
这只回答了最后一个问题。
并且从你的代码中，根本看不出你说的两个语义。
赫，应用本身可不知道啥是IOC，还是上面同银行接口的例子，你不会说，这个规则谁定的？居然不知道反向控制，不知道组件自己不能决定调用某个特定的服务，IOC咋

学的？
如果你回答不上其他的两个问题，就不避回答了，显然没多少真实项目的经验，今后举例弄些和实际粘点边的，要不碰到我这种可就麻烦了。
问这些问题当然有目的，做过项目的人凭常识都知道session是thread级别的singlton，你非把它弄成个prototype，有这样用的吗？
你不过是想指出spring不具有管理prototype类型bean的能力而已。这完全不同于我们前面讨论的Domain调用外界服务的问题。

另外，俺懂不懂IOC,如何使用spring与本次讨论的主题无关，你没必要多次强调。

最后明确一下主题，针对domain调用外部服务IOC和AOP解决方案的对比

这不是跟你学的嘛.
怎么?才问一下就受不了了?
你的回答我怎么看不出来逻辑关系亚?你要说啥呀?要说你这个设计有道理?怎么没看出任何理由来呢?
还是麻烦把需求明确的写出来，然后把代码好好整理整理，别总出局部变量定义成全局这种低级错误。


呵呵。那么你是相信你有这种能力来质疑别人的能力乐?不过，这种质疑别人能力的辩论手法一般都被认为是很下作的哦。
你连代码要自己说明自己都怀疑了，那我还说啥。你可真有能力，只怕gosling也没你这种能力和大无畏的革命精神什么话都敢说。

好。既然承认只代表你自己。那就不要说话动辄象客观真理的代言人。什么“根本不应该”的话，还是悠着点说。
至于让我展示一下什么的，你先举个你的设计例子再说，免得空对空。


那你看出来“不具有这两个语义”了么？
这本来就是个例子，目标不是展示这两个语义，而是说在存在这种语义的前提下,怎么样设计比较好.
你从开始到现在始终孜孜不倦吹毛求疵地在例子上下功夫.也不知道是繁重的项目把头脑搞迟钝了还是存心抬杠?


是啊。碰上你这种鸡蛋五毛钱俩，一块钱不卖的主是够麻烦的。:lol:
我可没心思非得就着你，分两次，一次买五毛钱的这么麻烦。


又在例子上做文章。又在把自己当成客观真理和“所有做过任何项目的人”的代言人。你可真强。



你不懂ioc，很多话题就根本没法谈。因为一些约定俗成的基本常识你没有，从头给你讲什么是ioc以及ioc的好处太累人啊。你就不能体谅体谅？




都不用比较依赖注射了。就这种aop解决方案还不如直接service locator呢。我不注入，就这样：

class BankAccount{
  void f();{
    //估计这里又要该挑剔“做过项目的人都知道不会给函数起名叫f”乐。
    SmtpService service = GlobalDependencies.getSmtpService();;
    ...
  }
}

同样是单点控制。

你先说说，你这个aop方案比这个service locator好在哪？

ajoo:
呵呵。那么你是相信你有这种能力来质疑别人的能力乐?不过，这种质疑别人能力的辩论手法一般都被认为是很

下作的哦。
你连代码要自己说明自己都怀疑了，那我还说啥。你可真有能力，只怕gosling也没你这种能力和大无畏的革命

精神什么话都敢说。

partech:
很不错！能够意识到“质疑别人能力的辩论手法一般都被认为是很下作的”。
多谢提醒！

partech:
最后明确一下主题，针对domain调用外部服务IOC和AOP解决方案的对比

ajoo:
都不用比较依赖注射了。就这种aop解决方案还不如直接service locator呢。我不注入，就这样：

java代码: 

class BankAccount{
  void f(){
    //估计这里又要该挑剔“做过项目的人都知道不会给函数起名叫f”乐。
    SmtpService service = GlobalDependencies.getSmtpService();
    ...
  }
}
同样是单点控制。

你先说说，你这个aop方案比这个service locator好在哪？

partech:
嗯，想转移话题？“单点维护”还是值得追求的？
如此，结帖。

AJOO:

我认为，aop和proxy/decorator模式的区别就在于：
aop的织入是侵入性的，破坏因果关系。而proxy/decorator虽然提供了非常相似的功能，但是它们都是由程序直接控制，符合因果关系的。
用ioc的代码，在java语义内部所有问题都可以得到解决，你可以手工注射依赖。
滥用aop的代码，（比如这个domain injection）
在java的语义范围内逻辑是不完整的，你无法只用java语言本身来让它工作。
是的，这个侵入的问题是很头痛的问题，有可能成为致命的问题。
AOP有滥用的趋势，它的存在本在于解决某部分的问题。 而不是全部的问题。
如果让我选择一种方式来做丰富领域模型， 我会选择ServiceLocator的方式，毕竟这是简单而实用的东西。大家也不用在此发这些没什么意义的争论了。

支持firebody,何必在ioc这条贼船上吐死呢.

反对，为了这么点小事，就要引入一个侵入式的语义模型，这不是拿把刀往自己脖子上架吗？

怎么这么多人在不停的跟ajoo真论啊, 呵呵, ajoo的魅力还是那么大哈.

我支持ajoo. 在我看来, ajoo一直不停的在表达的一个意思就是不要死板, 不要生搬硬套, 不要迷信.

OO的精髓不是为了OO而OO, 提出OO的初衷也是为了解决问题, 并且一个问题从不同的角度去看会有不同的形式和表现, 但是更重要的是, 不管它有多少种侧面, 有多少种表现形式, 这个存在的实体都是同一个, 对我们来说, 我们的任务只是从这些众多的侧面和表现形式中选择一种最简单, 最方便, 最合适的, 以便能够最好的达到我们的目的.

不要非得强调OO不可, 在不同的处理层次上, 同一事物实体的表现是不同的. 似乎也有人说STL不是OO, 可是那有什么关系, STL带来的设计上的飞跃谁能否认?

把自己当成设计师, 不要把自己当成OO师了.