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出場了。
