【導讀】本文檔是由CASA有限公司的BenediktStefansson在1998和1999年的。SwarmFest上發(fā)表的Swarm教程材料發(fā)展而來的。分三個階段逐步深入的討論了Swarm工具：第一部分是。Swarm的簡介；第二部分深入地剖析了Swarm程序；第三部分則詳細討論了用戶在使用Swarm開發(fā)程序。時可那遇到的種種問題。鼓勵用戶探索Swarm提供的樣例程序，并訪問Swarm站點（。來了解最新消息和加入Swarm郵件列表。PaulJohnson的工作，由國家科學基金會的基金部分支持。Paul是主要的作者，提供了《指。南》的主要材料。不允許大量分發(fā)本文的復制品或者將之用于牟利。生成本文檔的SGML源文件以及相關程序。Swarm項目由ChrisLangton于1994年在新墨西哥州的圣塔菲研究所（SantaFeInstitute，現(xiàn)在由圣塔菲研究所的非盈利性組織Swarm開發(fā)組。遵守GPL許可的部件，這意味著Swarm是遵守GPL的。庫做了改進，我們鼓勵他宣布出來并供他人使用。Swarm發(fā)布，其應用范圍進一步擴展。目前Swarm開發(fā)組的工作重點是使得Swarm. Swarm的出發(fā)點是為設計多主體模型提供一系列的標準化方法。以輕松的測試Swarm的樣例應用程序。

　　

【正文】 { theTopLevelSwarm = [HeatbugObserverSwarm createBegin: globalZone]。 SET_WINDOW_GEOMETRY_NAME (theTopLevelSwarm)。 theTopLevelSwarm = [theTopLevelSwarm createEnd]。 } 在大括 號中的第一個命令通知 HeatbugObserverSwarm 類執(zhí)行 createBegin 方法，并返回名為theTopLevelSwarm 的對象。在本例中， HeatbugObserverSwarm 是一個“類工廠”對象，即可以創(chuàng)建所屬類的實例的對象。第二個命令是一個保存窗口位置的宏，在 createBegin 和 createEnd 中設置是因為它設置的是對象的永久屬性。最后一個命令標志著創(chuàng)建過程的結束。 在 Swarm 參考指南中，很多協(xié)議的方法屬于三個階段之一：“創(chuàng)建”，“設置”和“使用”。要注意某個方法究竟屬于哪個 階段。創(chuàng)建階段的方法和宏只能在 createBegin 和 createEnd 之間使用。如果這樣的方法在 createEnd 之后使用，將會導致程序執(zhí)行失敗。同樣，使用階段的方法只能在 createEnd 之后使用。設置階段的方法則可以在對象生命周期的任何時候使用。 詳細了解 createBegin/createEnd 現(xiàn)在看 中調(diào)用的 createBegin 和 createEnd 方法。在 中會發(fā)現(xiàn)方法+createBegin 和 createEnd。 createBegin 前面的加號表明該方法不能被 HeatbugModelSwarm 類的實例執(zhí)行，只能被類工廠對象執(zhí)行。下面是 createBegin 的片段： + createBegin: aZone { HeatbugObserverSwarm *obj。 id ProbeMap probeMap。 obj = [super createBegin: aZone]。 objdisplayFrequency = 1。 //此處略去創(chuàng)建探針圖的代碼 return obj。 } 上述例子很好地 展示了 Swarm 是如何處理對象創(chuàng)建的。首先定義了指向類 HeatbugObserverSwarm 的指針obj。由于 HeatbugObserverSwarm 是 GUISwarm 的子類，因此必須確保 GUISwarm 對象中所有的重要變量都被初始化了，并被 HeatbugObserverSwarm 所繼承。上述工作只需一步：通知超類執(zhí)行其 createBegin 方法。由于類之間彼此聯(lián)結成為一個體系結構，每一個更高層的類都會執(zhí)行自己的 createBegin 語句。這樣，這樣對象就可以設置其繼承的所有變量的值。 超類的 createBegin 方法被調(diào)用，并將所創(chuàng)建的對象置于 aZone 中， aZone 是從 傳遞進來的內(nèi)存空間名字。內(nèi)存空間被返回傳遞給 obj。然后語句 return obj 將所創(chuàng)建的對象返回給調(diào)用代碼 —— 在本例中就是。 會將創(chuàng)建的對象設置為 theTopLevelSwarm。 讀者研究 Swarm的相關源代碼，就會發(fā)現(xiàn) GUISwarm通過一個類體系鏈繼承了創(chuàng)建內(nèi)存區(qū)域和對象的能力。Swarm 是 GUISwarm 的子類， GUISwarm 繼承的源頭可上溯到 CSwarmProcess，該類的定義詳見文件，也正是在這個文件中第一次出現(xiàn) createBegin 和 createEnd 方法。因此，文件 SwarmProcess中的相關代碼就是調(diào)用 super 的方法時所執(zhí)行的代碼。 中的 createEnd 方法非常簡單： createEnd { return [super createEnd]。 } 如上例所示，由于超類被隱藏在 Swarm 庫中，因此很難準確地說出為什么需要 createEnd 這個命令。事實上，本例中根本不需要執(zhí)行它，當然加上了也沒 什么壞處。顯式地調(diào)用 createEnd 方法，就可以確保超類的createEnd 方法被執(zhí)行，這樣做的重要性在于這些步驟初始化了本類所繼承的某些變量。 有時 createEnd 語句具有更重要的作用。在 createBegin 階段，通?？梢园l(fā)現(xiàn)設置對象的永久屬性的命令，可能還包括一些初始化實例化變量的方法。在上例中， *obj 的變量 display frequency 被設置為 1。這些變量首先被設置是因為其它的變量取決于它們的值。調(diào)用了 createBegin 后， 可能還包括進一步設置對象狀態(tài)的語句以及與在 createBegin 中所設置的參數(shù)值相關的命令。最后， 通過調(diào)用 createEnd，進一步執(zhí)行定義對象元素的命令。 在 createEnd 語句中最適合放置完成對象初始化的代碼。例如，假定有一個變量 age。在 createEnd 中，可能找到如下的代碼： createEnd { [super createEnd]。 age = 0。 return self。 } 在上面的代碼中，首先執(zhí)行的是 createEnd 方法，這可以確保在其中初始化的變量被正確地賦值。然后實例變量 age 被賦值為 0。 實際上， 發(fā)送 create 消息就可以使消息的接收者執(zhí)行 createBegin 和 createEnd 方法。那么為什么不總是使用create？這是因為有時需要在 createBegin 和 createEnd 之間的階段定義變量，如上面的 文件中所示。如果沒有這樣的需要，完全可以使用 create 就行了。 Swarm 的（內(nèi)存）區(qū)域和遞歸對象的創(chuàng)建 在計算機程序設計中最麻煩的事情就是動態(tài)分配的內(nèi)存的管理。要正確的使用動態(tài)內(nèi)存需要十二萬分的小心。當某部分內(nèi)存不再需要的時候，必須釋放之。如果被分配的內(nèi)存忘記了釋放，這 被稱為“內(nèi)存發(fā)生了泄漏”，因為程序忘記通知操作系統(tǒng)有些內(nèi)存不再使用了。 Swarm 庫中的設計使得用戶可以幾乎不干預內(nèi)存的動態(tài)處理。 createBegin 和 create 命令被用來分配內(nèi)存，用戶無須考慮對象被存在 RAM 何處。同樣，當不再需要程序中的某個對象時，發(fā)送 drop 消息給該對象即可， drop 消息會仔細處理對象所使用內(nèi)存的釋放。 在 Swarm 中， create 語句一般如此使用： someUserCreateObject = [SomeSwarmLibraryObject create: someMemoryZoneHere]。 （ create 方法等同于 createBegin/createEnd 對，如前所述）。 下面將討論很多相關的例子，并將貫穿到 Swarm 的樣例程序中。有一點非常重要： Swarm 中的對象能夠創(chuàng)建對象本身的實例。實例存在于內(nèi)存區(qū)域中，由 Swarm 庫管理。 在 文件中，最頂層的 Swarm 被創(chuàng)建在被稱為 globalZone 的內(nèi)存區(qū)域中，它是 Zone 類的實例。 theTopLevelSwarm = [HeatbugObserverSwarm createBegin: globalZone]。 globalZone 是在 Swarm 程序一開始調(diào)用 initSwarm 函數(shù)時被創(chuàng)建的。隨后最頂層的 Swarm 被創(chuàng)建在globalZone 中。任何類型為 Swarm 或者 GUISwarm 的對象都可以充當內(nèi)存區(qū)域。在 ModelSwarm 中可以發(fā)現(xiàn)： probeMap = [EmptyProbeMap createBegin: self]。 上面的語句告訴 EmptyProbeMap 類在 ModelSwarm 分配的內(nèi)存區(qū)域中創(chuàng)建自己的實例對象，名字為probeMap。 在 swarm 體系結構頂層的對象（ Swarm 或 GUISwarm）有權為對象創(chuàng)建它們可以生存于其中的空間。在 的代碼中，首先是對象 theTopLevelSwarm 的創(chuàng)建，接著申請內(nèi)存的分配并設置需要在此期間初始化的重要變量的值。最后，剛剛被創(chuàng)建的對象需要連續(xù)執(zhí)行： [theTopLevelSwarm buildObjects]。 [theTopLevelSwarm buildActions]。 [theTopLevelSwarm activeIn: nil]。 [theTopLevelSwarm go]。 看看 theTopLevelSwarm 的 buildObjects 方法的內(nèi)部代碼，發(fā)現(xiàn)了什么？隨著 Heatbugs 代碼版本的不同，可能會發(fā)現(xiàn)： heatbugModelSwarm = [HeatbugModelSwarm create:self]。 在上面這句代碼中， self 處于 observer 層，這意味著 HeatbugModelSwarm 將在 observer 提供的內(nèi)存區(qū)域創(chuàng)建名為 heatbugModelSwarm 的對象。 如果深入到 文件的內(nèi)部，會發(fā)現(xiàn) createBegin 命令，該命令初始化了很多實例變量和對象。這些對象都在內(nèi)存區(qū)域 self 中被創(chuàng)建， self 是 model swarm 自己提供的空間。 類型為 SwarmObject 的對象并非內(nèi)存區(qū)域，因此當在繼承于 SwarmObject 的類中創(chuàng)建對象時，必須有申請內(nèi)存的命令： bugPixmap = [Pixmap createBegin: [self geZone]]。 在上面的語句中， bugPixmap 被創(chuàng)建在 中，但是對象所存在的內(nèi)存區(qū)域是由 [self getZone]命令返回的。 [self getZone 將返回 bug所在的內(nèi)存區(qū)域名字，即 heatbugModelSwarm。 使用 Swarm 對象庫和頭文件 在使用 Swam 中，對象的出現(xiàn)經(jīng)常顯得神出鬼沒?；蛘吒侠淼卣f， Swarm 庫提供對象的方式往往不是那么明顯的。例如，假定想要創(chuàng)建一個對象列表，那么可以首先聲明一個名為 listOfFriends 的對象，然后創(chuàng)建對象列表。如下所示： id listOfFriends。 listOfFriends = [List create: self]。 在 Swarm的樣例代碼中，經(jīng)?？梢钥吹较裆厦孢@樣的代碼。 List 類哪里來的？為什么無需在程序 頭輸入 就可以直接使用它？一般來說，如果想要使用 List 類，應該在源文件頭包含 ，對吧？ 對于很多 Swarm 類來說，由于不是要進行子類化，因此無需顯式地包含相關的頭文件。相反，需要包含“通用目的”的頭文件，這些頭文件對應了 Swarm 庫的主要部分。例如，要創(chuàng)建 List 對象，需要包含 通用目的 的 ，該頭文件不僅包括 List，還包括其他的集合類。 “通用目的”的頭文件位于 Swarm 的 include 目錄下，計有： ? ? ? ? ? ? ? ? ? 在《 Swarm 參考指南》中，可以看到很多協(xié)議都采用了 CREATETABLE 協(xié)議，這意味著用戶可以在自己的代碼中用它們創(chuàng)建對象。使用這些類時，需要包含上述的頭文件之一。例如，要創(chuàng)建 List 對象，需要包含 。任何文件，只要是創(chuàng)建 List、 Map、 Set 或其他類型的集合對象，就必須包含該文件。 用戶在自己編寫的 .h（頭）和 .m（實現(xiàn)）文件中必須將 “通用目的”的頭文件包含進去嗎？一般來說，只是 .m 文件才需要這樣做，因為正是在 .m 文件中創(chuàng)建對象的。唯一的例外是當在頭文件中引用協(xié)議時。例如，如果想聲明一個采用 List 協(xié)議的對象，就需要在頭文件中包含對應的通用頭文件 ，如： id List aList。 如果忘記了包含 ，編譯器會通不過，并報告存在解析錯誤。這是由于在該頭文件中找不到名為List 的類或者協(xié)議的定義，因此編譯器認為這是一個編輯錯誤。 與之相反，如果頭文件使用的是一般性聲明，如： id aList。 則無需在頭文件中包含 ，僅在用戶類的實現(xiàn)文件中包含進去就可以了。 顯式地包含與某個類相關的頭文件僅當要子類化該類時才需要。由于用戶的頭文件聲明了正在創(chuàng)建的用戶類，并引用了超類，因此在頭文件中必須包含與超類相關的所有頭文件。例如， SwarmObject 是最常用到的超類，以 SwarmObject 為超類的用戶類的頭文件必須既包括通用的頭文件 又包括objectbase/。 以上可歸結為兩條法則： ? 如果用戶在自己的程序中使用了符合 某種協(xié)議的類（例如 List）來創(chuàng)建對象，則需要包含相關的通用頭文件。 ? 如果正在對遵守某個協(xié)議的類進行子類化，還需要包含該類的頭文件。 需要著重指出的是：并非所有的 Swarm 協(xié)議都允許被子類化。例如，為了避免某些難以克服的困難， List不能被用于創(chuàng)建用戶類。用戶可以創(chuàng)建 List 對象并使用之，但不能創(chuàng)建 Swarm List 類的變體來適應自己項目的需要。 作為良好的編碼習慣，代碼文件應該保持清潔：每個文件只包含真正需要的頭文件。別把“所有的頭文件”都包含進去。 其它的方法 知道了對象是如何創(chuàng)建的， 接下來要考慮的問題就是仿真程序是如何組織的。標準的 Swarm 程序采用這樣的