面向对象软件开发
- 充分利用继承，增强代码复用
- 继承机制的使用需要强大的思维抽象能力
关于操作者框架
- 绕开任务树
- 本范例项目特意在一个位置中断了任务树。“冷却器”和“冷却器控制器”操作者处于任务树的不同分支，但本范例项目将两者的当前类待入队列发送给对方，从而使得它们能够直接互相通信。该代码包含在“气冷系统应用程序”类的“操作者核心”方法中。
- 直接进行通信的原因是，根据本范例项目的设计方式，控制器和冷却器操作者互相高度耦合。冷却器和控制器需配合使用。不必通过“应用程序”操作者发送消息。
- 为什么不要绕开任务树
- 任务树破坏了AF框架的完整性
- 实际上如果让某两个子操作者能够直接通信，则最后的架构会是的每一个子操作者都是一个独立的个体，这样的架构和ROS的分布式体系一致。
- 但是，实际上我们并不需要这样的架构，我们恰恰需要这样的架构：每一个子操作者是受控的，主操作者经过规划之后决定这个消息是否发送给子操作者，而子操作者只有在接受到消息之后才执行相应动作
- ROS的消息机制略有不同，所有消息均存储在一个所谓的“消息管理器”节点上，其他节点可以选择将消息从管理器节点获取或发送到该节点，此时各个节点是不可控的，消息管理器也是不可控的。
- 发送消息时忽略接收方类型
- 由于大多数消息设计为被一个特定类型的操作者接收，这种设计与典型的“执行”VI设计不同，“执行”VI首先检查接收方的类型是否正确。如检查失败，则“执行”方法从“转换为特定的类”函数返回错误，从而将错误报告至操作者的“处理错误”方法。大多数消息类采用此设计方式，避免命令发送至不正确的操作者。例如，DAQ命令被发送至仅能理解GPIB命令的操作者。
- 设计重复使用的操作者
- 使用“零耦合模式”的消息机制，当需要将消息发送给调用方时不需要验证调用方的类型。该模式使用所谓的“抽象消息”得以实现。抽象消息是一个包含基本设置的消息，但没有收到消息时调用方执行何操作的命令（即do 函数）。相反，每个类型的调用方为操作者提供该调用方的一组指令。
- 设计重复使用的操作者会增加一定的编程复杂度。然而，这种设计的好处在于用户可以将操作者和任何类型的调用方重复使用。由于操作者带有一个被调用方填充的占位符，所以用户将为每个类型的调用方创建一个抽象消息类的子孙类。每个类型的调用方使用调用方能够理解的消息填充占用符。
- 操作者应该有名字
- 如果有一模一样的操作者，应该要在簇数据结构中命名。
深刻理解“零耦合”消息机制[PDF]
- 在发送端建立虚消息类
- 命名
- 写属性
- 建立类，放到“虚消息类”文件夹
- 在接收端建立虚消息类的子类
- 选择将要继承的虚类
- 建立消息类，放到“消息”文件夹
- 注意
- 哪一个操作者有“虚消息类”文件夹，则这个操作者是发送端。