swarm用户手册

swarm用户手册内容摘要：

FoodSpace foodSpace。 public Object setX$Y (int x,int y) (5) { xPos = x。 yPos = y。 return this。 } public Object step()(6) { // body of step() code return this。 } public return_type look(direction_type d) (7) { return_type returnval。 // body of look() code return returnval。 } } (1) 完整的类定义 (2) 子类 (3) 超类 (4) 实例变量 (5) 声明方法 setX$Y()，有两个参数 (6) 声明方法 step()，无参数 (7) 声明方法 look()，有一个类型为 direction_type 的参数，返回值类型为 return_type 注意在 Java 中并没有 id 这种类型或其他一般的数据类型。 所有的变量都必须被分配一种类型，在上例中，实例变量 foodSpace 被声明为 FoodSpace。 这是由于 Java 语言是强类型语言。 编译器会检查所有变量的所有类型，以确保所有的接收代码能够对得到的消息进行响应。 除此之外， Objective C 和 Java 代码之间的最主要区别纯粹是因为语法的不同。 例如，  在 Objective C 中，方法名字和参数是散布的；在 Java 中完整的方法名字必须列在参数之前。  在 Java 中，使用 this 而不是 self（ super 在两种语言中的含义和语法都是相同的）。 类的实例化 实现类的代码（也就是 Objective C 的 .h和 .m 文件， Java 的 .java 文件）后，还要做的工作就是创建类的实例。 实例化： Objective C 风格 仿真中的角色对象通常是 SwarmObject 类的子类。 通常使用一对命 令来创建对象： createBegin 和 createEnd，这不属于 Objective C 语法，是 Swarm 特有的。 假定已经存在 和 ，现在想创建类的实例。 在文件 中，建立一个典型的方法buildObjects，在其中完成所有的对象创建。 例如： // 摘自 ，创建 Bug的实例 import // {其它的输入和代码 } buildObjects { id aBug。 bug = [Bug createBegin: self]。 // 设置主体的永久特性的代码 bug = [Bug createEnd]。 } 类工厂对象 Bug被告知在 ModelSwarm 提供的内存区中创建一个对象（ ModelSwarm 就是 self）。 然后对象aBug被创建，可选的属性被加入。 在后面的部分将深入讨论上述细节（也可参考附录 B）。 创建对象的实例不一定要用 createBegin/createEnd 对，可以简单地处理为： aBug = [Bug crate: self] 在基于老版本的 Swarm 的代码中，语法有所不同： aBug = [Bug create: [self getZone]]。 在 Objective C 中，这种用法仍然是有效的，但是不鼓励这么做。 由于现在属于 Swarm 类型的对象，跟ModelSwarm 一样，都是内存区域，因此无需再申请一个放置 Bug对象的区域了。 实例化： Java 风格 Java 使用构造函数来创建类的实例。 创建 Java 对象 Bug的最简单方法如下所示： aBug = Bug (())。 这等价于前面所述的 Objective C 样例。 Objective C Java aBug = [Bug create: [self getZone]]。 aBug = Bug (())。 注意在 Objective C 需要明确指出的 create:方法在 Java 中是隐含的。 备注：在 Java 中仍然可能使用 create 和 createBegin/createEnd 这种模式，但由于 Java 是强类型的语言，因而需要更多的工作才能使用上述模式。 详细情况将在后续版本的指南中讨论。 简要的澄清： Objective C 中的类和协议 读者需要仔细研究的一点，是 Objective C 允许创建叫做协议的实体。 协议，是一个对象可以执行的方法列表。 Swarm 的结构由协议组成，因此在 Swarm 的参考材料中，将库看作是类的集合，每一个类又与给定的协议集保持一致。 对 Swarm 用户来说，很多情况下都不必区分类和协议。 最重要的 Swarm 协议，如类型 Swarm（来自objectbase/）或 Swarmobject（来自 objectbase/），可以将之当作类一样的使用。 在Swarm 的参考指南中，有所有的协议的列表。 采用 CREATABLE 协 议的协议，可以将之视为类工厂对象。 例如， EZGraph 协议采用了 CREATABLE 协议，因此当用户要创建该协议的实例时，就可以直接使用。 这样， observer swarm 文件就可以用 EZGraph 创建图。 几乎所有的 Swarm 协议都采用了 CREATABLE 协议，因此可以将之视为类一样的使用。 例如协议SwarmObject，采用的协议包括 Create， Drop 和 CREATABLE。 这意味着 SwarmObject 可以被视为一个类，SwarmObject 将响应 createBegin 消息， SwarmObject 创 建的实例对象将能响应 createEnd， drop 以及协议中列出的其他方法。 使用协议的一个原则性好处是在编译的过程中，如果用户代码试图向对象发送非法的消息，编译器将发挥警告信息。 例如，有消息通知对象执行方法 goOutside，但是主体所采用的所有协议中都没有该方法，此时编译器将对此给出警告。 粗略地说，采用协议就好比广而告之了某个类所能完成的功能，随后编译器确保了个中的“诚信”。 如果编译的标志中包含 WERROR，也就是将警告视为错误，那么出现的警告信息将停止编译过程。 事实上， Swarm 库的很多重要部件 都组织为协议，但是早期版本的 Swarm 不如当前版本在这方面那么突出。 由于协议的引入，使用约定发生了改变。 在 Swarm 中，有一个可用于创建集合的类 List。 使用老版本的Swarm，程序设计者可以创建属于 List 类的静态类型对象，如下的代码所示： List * listofPuppies。 lisofPuppies = [List create: [self getZone]]。 Swarm 已经不允许用户采用上述方式静态的定位对象。 这样的代码将使得编译器崩溃，因为在 Swarm 中没有名为 List 的类，只有上述命 名的协议。 从 Swarm 参考指南中我们知道协议 List 采用了 CREATABLE 协议，因此错误不是由于使用 List 创建listOfPuppies 引起的。 实际上，错误源自 listOfPuppies 的声明本身。 如果需要定义的变量 listOfPuppies 由List 类项目组成，推荐的方法是创建一个类型为 id 的变量，然后用尖括号指明对象所采用的协议： id List listOfPuppies。 listOfPuppies=[List create: [self getZone]]。 将 listOfPuppies 定义为为一般对象也是合法的： id List listOfPuppies。 listOfPuppies=[List create: [self getZone]]。 这种用法是合法的，编译也不会存在任何问题。 唯一的缺点是如果往 listOfPuppies 中的对象发送了任何不正确的消息都不会得到警告。 由于几乎所有的 Swarm 库重要功能都以协议的形式实现并且采用了 CREATABLE，因此了解上述细节就显得尤其重要。 但是，这并没有对程序设计的方法进行大的改变。 Swarm 的实体仍然可以被视为类。 第四章 Swarm 的开发思想 如前所述，设计 Swarm 的目的是创建层次化的计算机对象。 首先， observer 类的 swarm 被创建，从而创建了用户接口并实例化 model 类 swarrn，后者创建了后续层次的对象，并对主体的活动进行调度。 Swarm 项目的初始目的之一就是帮助用户方便地创建高质量的代码。 Swarm 库提供了一系列的类：创建仿真对象，管理内存以及调度主体的活动。 主要主体和辅助主体 由于计算机程序员使用“主体”的方式与科学家不一样，因此需要对术语的含义进行澄清。 对于科学家来说，主体 是指仿真中被建模的具有重要理论意义的实体；对于程序员来说，主体的用法就比较广泛了，有时候含义等同于对象。 这样，在对“基于主体建模”的讨论中有时会发生错位的现象，因此大家对术语“主体”的理解不一样。 为此，我们定义类两类主体：主要主体和辅助主体，以有利于进行相关的讨论。 所谓的主要主体是指研究中首先要建模的东西，在理论中得到了描述，并具有实在的重要性。 通常在这个意义上，可以对重要的“角色”以及角色之间在其中进行交互的世界进行表示。 让很多新手感到惊讶的是，为了方便主要主体的工作，还需要创建辅助主体。 例如，在 一个遵守多数票当选的选举模型中，可以有像投票者和候选人这样的主要主体，还可能需要名为计票员的辅助主体，以便对选票进行计数。 在大多数情况下，我们提到多主体系统时，是指主要主体。 （ Swarm）面向对象程序设计方式 在 Swarm 中， ObserverSwarm 和 ModelSwarm 的设计方式大致一样。 在大多数类中都会出现的方法，包括： Objective C Java createBegin。 createEnd。 buildObjects。 createBegin()。 createEnd()。 buildObjects()。 buildActions。 activateIn。 buildActions()。 activateIn()。 此外还有涉及对象的信息的输入 /输出的方法。 习惯上，这些方法的名字都有前缀 get 或 set。 例如： Objective C Java setParameterValue: (int) value。 (int) Object setParameterValue (int value)。 int getParameterValue。 getParameterValue()。 方法 setParameterValue 能够对对象的内部参数进行赋值；而 getParameterValue 则使得主体汇报自己的参数值。 除此之外，还应该有针对于研究问题本质的方法。 ModelSwarm 对象通常直接子类化于 Swarm，是负责创建主体的主要对象，还给主体提供了内存区域，嗯并能对主体的活动进行调度。 Swarm 中的内存管理 在任何仿真项目中，内存的申请和释放都是必需的特性，也是软 件设计中最容易出问题的地方。 Swarm 在内存管理方面性能比较卓越，提供了对用户透明的相关库。 在 Swarm 中，对象的创建和销毁涉及一个概念是内存区域，申请内存的“脏活”由库来处理。 在下一部分中，我们将讨论对象的创建方式以及对存储区域的占用。 当不再需要这些对象时，程序可以对对象发送 drop消息，将之从内存中卸载。 buildObjects 方法中要做些什么。 用户只须查看几个 Swarm 样例程序，就会清楚地发现创建对象的重要性。 在 buildObjects 方法中，人们可以发现不仅有创建在当前类中使用的 对象的命令，还有指示下一层主体创建其对象的命令。 以 Arbames 模型为例，在其 ObserverSwarm 的 buildObjects 方法中，首先是很多用于创建图形显示对象的命令，接着是创建仿真控制面板的命令，仿真控制面板呈现在屏幕上，为用户提供了开始和停止仿真的能力。 需要特别指出的是，在 ObserverSwarm 的 buildObjects 方法还触发了下一层主体的创建 —— 创建了一个内存区域，并在区域中创建了一个 ModelSwarm。 代码的样子大体如下： Objective C Java forestModelSwarm = [ForestModelSwarm create: self]。 forestModelSwarm = ForestModelSwarm [forestModelSwarm buildObjects]。 ( () )。 ()。 在 Objective C 中，用户可以发现旧风格的代码，没有考虑 ObserverSwarm 本身就是一个内存区域的。