摘要:前段时间一直周旋于各种有趣且辛苦, 或者无趣且更辛苦的事情当中, 虽然其间也切换到其他好些不同的技术领域, 但一直没有放弃在AOP方面的关注思考. 前面之所以没有能接着AOP这个话题继续和大家聊下去, 是因为感觉自己没有足够的精力和空闲来将这些想法沉淀下来, 并回锅为简单直白, 易于消化和理解, 并能引发思考的东西. 这几天, 出差在外, 工作之余免去了灶台内外的忙活. 油烟味少了, 人也觉得清爽许多; 闲暇多了, 就免不了想爬爬格子. OK, 闲话到此为止, 就让我们继续AOP的白话之旅吧J   简单回顾一下前一段旅程(一,二,三), 在前面我们简要介绍了什么是Agent, 这个东东的来由, 以及与其他重要概念, 如Object的区别. 如果说前段理论之旅展现的奇异风光令我们心神荡漾, 那么接下来的实践之旅就会又把我们拽回到繁杂而精密的软件世界中.   在前面也有介绍过, 目前好像还没有一个专门针对AOP的IDE, 这对于急于操练一把AOP的同志来说是个不大不小的尴尬. 不过好在Agent也是由Object脱胎而来, 基于目前的OOP语言, 我们也可以来过一把AOP的瘾. 这里我们选择的是.Net 平台下的C#. 为什么要选择C#,,,, 因为如果使用Java, 文章也就不会发在这里, just jokingJ 理论上说, 任何OOP语言, Java, Delphi, C++, 都可以作为哈里.波特同学手中的魔法棒, 点化出妙不可言的Agent. 之所以选择C#, 是看中他的优雅和简洁(补充一句, 直到现在俺依然固执地认为Delphi是最优雅的语言, 虽然Borland迫于生计不得不出售整个IDE部门, 但俺依然决意守望Delphi, 直到Delphi的桅杆没入海平面的最后一刻…)   翻翻讲述Agent理论的书籍就可以查到, 一个为理论界所接受的Agent需要具有如下若干特征:   l         代理性(Action On Behalf Others) l         自制性(Autonomy) l         主动性(Proactivity) l         反应性(Reactivity) l         社会性(Social Ability) l         智能性(Intelligence) l         合作性(Callaboration) l         移动性(Mobility)   My god! 光把这些名词理解一遍就让人头大了. 不多解释了. 简单点, Simple is good. 我们现在不需要迎合理论家挑剔的口味, 只需要创造一个具有不完全特性的Agent. 女娲同学造人的时候还不是就地取材, 捧着坨泥巴就捏上了J 另一方面, 作为整个AgentWorld的缔造者, 我们必需意识到这样一点: 上述这些特性, 是分层次的, 比如反应性, 和自制性, 这应该是位于Agent心智(Mind)最底层的特性; 而社会性, 智能性, 合作性等, 则应该属于Agent的高级心智, 需要其他心智能力的支持.......[阅读全文]

摘要:进入Agent世界 － 什么是Agent？        在前面的讨论中，说道了一下Object让俺们感觉不是很爽的地方。总结下来：OO并不是对现实世界最贴切的模拟。那么什么东东可以比OO更加贴近地来模拟现实世界呢？就目前看来，还是Agent可以担当起Object接班人的这个角色。   这里多插一段话。俺们可以注意到，不论是Object还是Agent，他们都有比较深的理论渊源，同时以指导实际软件开发为其价值导向。目前在软件开发过程中，俺们大量地使用着Object的概念，所以前面讨论凡是涉及到Object的，俺们都尽量使用开发人员熟悉的语境来描述，比如同步方法，异步方法，.Net平台中特有的delegate等等。而目前围绕Agent的工作大部分还停留在理论研究或者实验室原型的阶段，所以在下面关于Agent的讨论中，理论学术（白话：纸上谈兵）的味道会略为浓一些。俺会尽量结合同志们熟悉的生活中的例子来解释这些理论上的东东。   俺们遇到的第一个问题是Agent的定义是什么？这其实是一个蛮无聊的问题，能够在纸上默写出Agent的定义并不代表这位同志已经深刻地理解了Agent的含义。但这里还是罗列一下前辈们给出的若干关于Agent的定义。从五花八门的定义中俺们也可以体会一下Agent这个概念所包含的内涵的丰富性。   1.        The MuBot Agent "The term agent is used to represent two orthogonal concepts. The first is the agent's ability for autonomous execution. The second is the agent's ability to perform domain oriented reasoning."这个定义强调了Agent的自动执行能力和推理能力。   2.        The AIMA Agent "An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors."不知道给出这个定义的前辈是不是搞生物学的，怎么看Agent都像是由细胞核和一堆毛须组装成的原始生命体。   3.        The Maes Agent "Autonomous agents are computational systems that inhabit some complex dynamic environment, sense and act autonomously in this environment, and by doing so realize a set of goals or tasks for......[阅读全文]

摘要:Agent之前－Object世界   在说起Agent之前，俺们还有必要先敬拜一下Agent的前辈Object，因为Agent实际上是由Object“进化”而来的。这话说出来，可能有些读者同志不太高兴了，Object有什么不好吗？现在这么多复杂的系统，不都是基于OO的思想设计出来的吗？   然也，OO的确为提高软件开发效率做出了很大的贡献，但是在使用过程中，OO也暴露出了一些痒处：   痒处一：OO并没有对现实世界中的实体加以区分。 在OO世界中，所有的软件实体都是Object，现实世界中的一张发票和一为员工，映射到OO世界中都是一个Class。Class发票具有一些数据（日期，金额）和操作（效验，保存），Class员工也具有一些数据（姓名，职位）和操作（上班，下班），从映射的角度来看，任何现实世界的实体都是数据和操作的集合。但实际上，在现实世界中，发票和员工还是有区别的。区别在哪里呢？在于发票是一个物体， 而员工是一个有心智的实体。发票类的方法只能是被动地被调用，如果我们不调用，任何一张发票都不会自动的进行效验或者保存。而员工的方法调用与否，是由员工自己来决定的。今天生病了， 不高兴上班，上班操作就不会被执行，今天任务重，他就会自动执行加班这个操作。换句话说员工类的操作不是被动调用的，而是自发完成的。 这种只能被动调用和自发执行的区别，归结一下其原因，是因为员工具有自己的心智，而发票是没有的。传统的OO并没有引入这个区分，而这种区分的却失所造成的结果就是所有的操作都是被动地等待调用。虽然我们也可以引入计时器，或者多线程技术来模拟主动操作，但这种并不完全贴合现实世界的设计思路是不是让各位隐约感觉有些不爽呢。   痒处二：同步和异步被人为地剥离。 上面讲的是OO对有些东东没有区分，这点说的是OO对某些东东又多余地加以了区分。比如，现实世界中，老师对同学们说：“请把书翻到78页。”老师并不需要知道翻书这个操作对于同学们来说是同步操作还是异步操作，他并没有说“请把书同步地/异步地翻到78页。”换句话说，翻书这个操作是同步还是异步，对于调用者（老师）来说，是不需要知道的，同学们知道就OK了。但是影射到OO世界中，对于调用者来说，他在调用的时候，就必须知道是同步调用还是异步调用。归纳起来说，在现实世界中，调用方式这种知识，是被调用方拥有的，而调用方是不需要考虑的，但在OO世界中，这个知识由被调用方转移到了调用方。Something is different。体会一下，这种差异会带来什么样的问题。   痒处三：无法自然地模拟现实世界中的感知能力（Sensebility）。 举个烧菜的例子来说明感知能力。老妈教俺烧菜的时候，常用的语法是：“当什么什么的时候，就怎么怎么样”。比如：当水烧开的时候，把肉放进去；当鸡块炸至金黄色的时候，捞出锅来。这就是感知能力的例子。鸡块作为感知源，它的属性可以发生变化；俺作为感知器，可以捕捉到鸡块的颜色这个属性的变化。如果鸡块的颜色由肉色转变至金黄色，俺就必须做出相应的操作/处理：把鸡块捞出锅来。   这种感知能力在现实世界中是非常普遍地存在的，然而映射到OO世界中来，却显的有些别扭。如果我们将鸡块和人构造为两个Class，要想人能感知到鸡块上某个属性值的变化，首先想到的是使用观察者（Observer）模式，在.Net平台下呢，则是在鸡块类中构造一个delegate，然后将人的某个操作挂到这个delegate上，当鸡块颜色值发生变化的时候，触发这个delegate。这种方式至少存在三个让人感觉别扭的地方：   l         鸡块就是鸡块，为什么鸡块这个Class里面要包含一个额外的delegate呢，这个delegate的存在对于实现鸡块这个class本身的逻辑来说没有任何意义，对于鸡块的逻辑而言，这个delegate是完全多余的，这还只是颜色属性上的delegate，不难想像，如果外界还有其他Class需要感知鸡块类其他属性上的变化，会有更多的delegate，更多的与鸡块本身逻辑不相干的代码出现。   l         注意到一个比较细节的问题。俺在看到鸡块颜色变为金黄色后，执行的操作是把鸡块捞出锅。这个“捞出锅”的操作，是由俺的心智来完成的，不是受鸡块的心智指挥，它自己蹦出锅来的。而在上面提到的使用delegate的解决方案中，我们把“捞出锅”这个操作挂载到delegate上，则“捞出锅”是由鸡块当前占用的线程来执行的，如果将线程理解为心智的话，则意味着是由鸡块的心智控制着人将自己捞出锅。是不是很诡异J  更直白地说法是：应该有一个线程来处理鸡块颜色的变化，另外再有一个线程来收到颜色变化的通知，并执行“捞出锅”的操作。这里有同志应该说了：也好办，把delegate的机制修改为多线程的就OK了！的确是这样，但需要注意的是要保持多线程机制对鸡块和人的透明性，如果因为需要贴近现实世界而增加Class的复杂性，那也违背了我们的初衷。   l         最后一个问题比较有意思。在现有的delegate解决方案中，我们只能针对实例（Instance）进行注册，而不可以针对类型（Type）进行注册。什么概念呢？比如锅里面有十个鸡块，俺得把“捞出锅”这个操作到这十个鸡块上依次注册一遍，才能保证每个鸡块在适当的时机被捞出来。是不是觉得和现实世界中的实际情况有些出入J 如果能够提供针对类型的注册机制，只要将俺的后续操作到鸡块类上注册一次，在感知范围内的所有鸡块，管他是十块还是二十块，都能被俺感知到颜色上的变化并执行正确的后续操作，这样会来的更简洁，更自然。   上面罗罗嗦嗦给OO挑了些毛病。实际上归纳起来就一句话：OO并不是对现实世界最贴切地模拟。而软件世界的终极目标是为了模拟现实世界，既然OO并不是最贴切的模拟，问题也就暴露出来了，改进的余地也就显现出来了。     怎么改进？轮到Object的接班人Agent出场了。...[阅读全文]

摘要:Adrian同志有一篇关于Aspect Oriented Programming的Blog The Ted Neward Challenge (AOP without the buzzwords)，俺非常的喜欢。这篇文章中文翻译过来可以是“无废话AOP”，它从一个脱离了具体实现手段的视角，用简单清晰的语言向我们表达了Aspect Oriented Programming的本意：尽量将需求和实现的关系由1:N逼近至1:1。俺也非常希望能整出这么一个“无废话Agent Oriented Programming”，可是基于下面两点考虑，俺还是决定放弃：一个是Agent Oriented Programming不光是个有意思的技术话题，还与学术界，理论界有很深的渊源。要“无废话”，且饶有趣味地阐述这样一个理论问题，是相当有难度地，还是时不时有必要来点废话，才不至于让同志们看得睡着过去。另一方面，记得上学的时候，老师传授的读书体验是先把书读厚，再把书读薄。书读薄了，吃透了，归纳出来，写出来的都是精华，当然也就无废话；而俺现在还处于把书读厚的第一阶段，所以写出来废话会比较多一点。基于这样的考虑，这个系列的文章可以被称为是“白话Agent Oriented Programming”。     如果俺有足够的耐性把文章全整出来and您有足够的耐性看完所有文章，您会对以下的内容有一个大概的了解：   l         什么是Agent和Agent Oriented ProgrammingAgent这个概念并不是空穴来风，在理论界对它的研究已经很深入，Agent是Object的进化版本，进化的目的是为了让软件系统更贴近现实世界。从程序设计的角度理解，可以认为Agent就是绑定了Thread的Object。 l         为什么要整这么个概念出来，这个东东和其他一堆泛滥的概念的关系是什么可以说搞软件的人，特别是搞平台软件的人，本质上都比较懒，整天琢磨着怎么更懒，如果有个东东可以让100行的代码压缩到10行，将设计，调试，维护的时间由1天压缩为1个小时，他们就会将这种方法拎出来，凑成一个概念。OOP，AOP，SOA什么的基本上可以说都是这么整出来的（戏言戏说）。 l         怎么样在.Net 平台上实现Agent Oriented ProgrammingAgent Oriented Programming是一种思想，与平台无关。但既然是准备贴在以微软技术为主题的博客堂上，为了以示尊重，还是选择在.Net平台上实现的比较好。 l         俺们设计的一个Agent SDK，及其一些蛮有趣的特性实际上这个Agent SDK是俺们设计一个工作流引擎的副产品。在给大家做演示的时候，这个SDK倒是比上层的工作流引擎更能引起大家的兴趣（除了胸闷还是胸闷）SDK部分地实现了Agent的一些特性，例如AgentMethod，TimerMethod，Sensebility等。 l         未来之路这里的未来之路包含两个意思。一层意思是，围绕着Agent Oriented Programming，还有很多高级的特性等待我们去实现，例如移动Agent，合作Agent等。另一方面，对于任何思想，技术而言，光掌握其原理，明白是怎么回事，是不够的，还是得运用到项目中，创造效益，老板才会高兴，才会去下力气去推广。所以俺们也要考虑如何将这么好的东东应用到实际的项目开发中去。...[阅读全文]