量子编程法（002）：量子的确认

本节目录

    量子确认的由来

    源量子和继量子

    量子完整的数据结构

    运行一个示例程序

    量子编程法的进一步说明

 

量子确认的由来

上一节介绍了量子编程法的基本概念和运行机制。当时提到：量子还必须包含一个“确认函数”，以确认本量子是有效的。这就是本节要介绍的量子确认。

量子确认是由于量子编程法的实际需求而设计的。

量子确认的过程就是：在一个量子收到消息，执行它的动作前，必须满足“给定的条件”。如果“给定的条件”不满足，则不执行动作，也不再发送消息。因此，我们在量子数据结构中增加一个返回布尔值的“确认函数”，通过调用量子的“确认函数”来测试“给定的条件”是否满足。

例如，有一个包含控件对象的量子A，当你在执行另一个量子B的动作过程中引用这个控件对象，你必须要确认这个控件对象已经产生，否则程序就会出错。因此，就可以在量子A的“确认函数”中检查控件对象是否有效，有效则返回True，否则返回False。如果量子A的“确认函数”返回True则执行量子B的动作，否则不执行量子B的动作，也不再发送消息。

量子执行动作需要满足的条件可能不止一个。也就是说，一个量子可能依赖于其他多个量子进行确认，只有其他多个量子的“确认函数”都返回True才能执行自身的动作。

对一个量子进行确认的量子可能又需要其他量子来确认。例如，量子A需要量子B来确认，而量子B又需要量子C来确认，……。

这样一来，在量子的确认过程中，相关的量子之间又形成了一条链，称之为“确认链”。

源量子和继量子

为什么说“又”形成了一条链？因为上一节说过，在量子的消息传递过程中，相关的量子之间形成了一条“驱动链”。

驱动链和确认链是量子之间相互联系的两种模式，有了这两条链（联系模式），目前来说，可以解决大部分问题，不再需要其他链（联系模式）了。

由于一个量子可以向其他多个量子发送消息，一个量子也可以由其他多个量子进行确认，因此，驱动链和确认链从数据结构上看都形成了树型结构。

相对于驱动链上的某个量子而言，处于其上游（向该量子发送消息）的量子称为该量子的“驱动源量子”，处于其下游（接收该量子发送的消息）的量子称为该量子的“驱动继量子”。也就是说，一个量子从它的驱动源量子接收消息，向它的驱动继量子发送消息。

相对于确认链上的某个量子而言，处于其上游（对该量子进行确认）的量子称为该量子的“确认源量子”，处于其下游（由该量子进行确认）的量子称为该量子的“确认继量子”。也就是说，一个量子由它的确认源量子进行确认，对它的确认继量子进行确认。

量子与它的源量子和继量子的关系示意图如下所示：

通常，在对量子进行编程时所涉及到的只有驱动继量子和确认源量子，而驱动源量子和确认继量子则不必关注。换句话说，量子不需要知道是谁向它发送了消息，也不需要知道将会对谁进行确认。

有时将“驱动继量子”简称为“继量子”，将“确认源量子”简称为“源量子”。

 

量子完整的数据结构

到目前为止，已经将量子的所有功能原理都介绍完了，可以给出量子完整的数据结构（逻辑上的）如下：

量子类型QType：
｛
    变量Value：任意类型，量子的变量
    函数Valid() As Bool：量子的确认 
    过程Action()：量子的动作

    变量ValidSourSet：集合类型，其中元素为量子类型QType，“确认源量子”的集合
    变量DriveSuccSet：集合类型，其中元素为量子类型QType，“驱动继量子”的集合

    过程SendMsg(Succeed As QType)：子过程，向驱动继量子Succeed发消息
    函数ValidSour() As Bool：子函数，返回所有的“确认源量子”均有效
    函数ValidSelf() As Bool：子函数，返回量子本身有效
｝

其中函数Valid()有如下的逻辑结构：

Valid() As Bool

｛

         Return ValidSour() and ValidSelf()    //返回所有的源量子均有效与量子本身有效<