关于获取事件相应的结果

在不同的上下文之间通过事件进行交互,那需要得到返回值的情况下,还叫做事件么?我有些怀疑...因为事件发生就是发生了,其他领域对该事件有何种响应本应该和事件源无关的,但这种需求有确实存在,觉得很矛盾,但如果不使用事件确实又没有其他更好的方式来处理...
大家讨论讨论!

2014-04-15 20:44 "@wilsonp"的内容
不同的上下文之间通过事件进行交互,那需要得到返回值的情况下,还叫做事件么 ...

其实这个一去一回包含两个事件,过去我们被请求响应的思维给误导了,总是认为请求必然有响应,两者是同体的,这种同体就如同同体人绑架了个人,限制了个体自由。

我们将请求响应切分为两个事件,一个请求事件,另外一个是响应事件,这个角度简单转变为我们系统的可伸缩扩展性带来解放,不亚于人类直立行走对人类进化的意义。

保持上下文边界内的纯粹,和外界的沟通方式可以多种多样,方式很多。

也不能说那一种就绝对好和坏,这个根据具体来看,包括技术本身也有其差异。

我搞java几年,后来搞node,发现很多java的思路在javascript中并不适用。在java中很严肃很刻版的东西,在javascript中感觉没那么难实现也没那么严肃。

就好比外国xx国认为sex很正常啊,在我们华夏认为谈sex色变。嘎嘎

java很累“类”和刻薄,即便当初我也不承认。

哈哈,java是让高手和低手代码都差不多,属于工程公式化编程语言。让你感觉编程并不是很好玩。

和生活差不多,有些时候生活并不是那么严肃。有人听你会j2ee,他们会用尊敬的眼神看着你!即便他们并不是真的了解javaee,而只是感觉很高深名气很大,即便javaee有名是因为“违反人类心智模式”造成的。嘎嘎,所以BS还是很多的。

感谢gameboyLV 、banq、brighthas 的解答。

将请求响应切分为两个事件,确实是一个很独到的解决方案,将整个系统之间的交互全部使用事件机制进行交互,个人也比较倾向于这种解决方案。
这种方案换一种方式来看,其实也就是异步处理的结果,事件源先发出事件A,同时监听AR(即A事件的应答),但不会一直阻塞,而是可以去处理其他的逻辑,等检测到AR发生了,则处理AR。那么这种异步的处理方式是否需要未处理应答事件的事件缓存起来(因为客户端代码知道该事件确实是需要应答事件),一旦处理完成就释放掉该事件,这样就可以抛弃同步,全部采用异步来进行处理...不知道我的想法对不对?
[该贴被wilsonp于2014-04-16 10:30修改过]

不管是用什么语言,java也好,node也好...在解决问题的思想上应该归于统一,到最后只是采用的方式不同而已,就比如事件机制一样,node通过EventEmit来支持node本身的事件机制,java也可以通过类似的方式并结合EDA的思想来达到同样的效果,也有很多第三方的事件机制实现,比如guava 的eventbus就是一个很经典的实现,还有很多其他的(banq大大已经说过介绍过很多...嘎嘎)

恩,只能是想法类似,落实到实现大相径庭了。类似设计模式在java中很多,而很多是由于java的限制才出现的模式。

node和java的通信机制,好比是天然通道和后天重武器打通的味道,当然没有好坏是两个环境。java中一切都是严肃和重武器的感觉(咚...嗙),这个严肃不是批评而是事实。

java做任何东西都需要严肃对待,有时要动用重武器,这是好事。比如在和java社区的人或信奉者交流,这个严肃是要说成是好处的,就好比和严肃习惯的人说话。在和轻松的人说严肃,她可能不太喜欢了。这个取决听者。

gaga

看到gameboyLV的EDA实现中,异步事件的反馈是采用的语言级机制,就想到了是否可以采用java的Future机制来实现同样的功能,着手试试看先...