State Logic.vi是要复用的逻辑,Level Controller肯定要先从硬件读取输入,然后在进行逻辑操作,最后输出结果,输入和输出是和硬件有关系的,但是硬件不同,故读取功能的代码和输出功能的代码肯定不一样,为了使软件可扩展性更好,所以将输入get new level.vi和输出set output state.vi作为虚函数(就是明知程序中必须有,但是又不能写在此类中),这样更换硬件时,我们只需从此类继承,并重写输入输出vi即可。另外,此类重写了Update.vi。重写的update会以固定间隔运行。
3. 创建 Water Level.class
Water Level是一个具体类,继承自Level Controller。前面的Level Controller和Time Loop Controller是虚类,类似于c++中的虚类,不能够实例化对象,labview虽然没有这个规定,但这样做没什么意义。
labview中,虚类负责逻辑设计,具体类(子孙类)负责具体的输入输出,和具体的硬件相关,这样带来的好处是,硬件更换时,只需要从虚类继承那些已经被设计好的逻辑,重写那些输入输出等和硬件有关的vi即可。
为了使软件有最大的灵活度,还要创建一个abstract user interface layer,AUIL,虚的用户界面。AUIL包括了UI类支持的所有消息和应该包含的公共代码。Cooler将能够向AUIL的任何子类发送状态消息。
8. 创建Cooler UI with Events.class
这个Actor操作者就是AUIL,虚类
Cooler UI with Events。
当然首先Cooler UI with Events要继承自Actor。Cooler UI with Events将会从Cooler操作者中接收消息,然后这些消息会被此类转化为用户事件user events,最后由本类的事件结构处理。此类的所有子类都会注册这些事件,当子类接收到消息时,会更新前面板——UI。
先看它的私有数据:
下面是这个库是这部分的所有功能。这里面Cooler UI with Events包括了所有功能,除了显示。为了使系统整容更方便,这里使用Cooler Panel这个子类来负责颜值部分。当审美疲劳时,随时可以通过继承Cooler UI with Events获得新的面目。
1.
Cooler.lvclass:Get New Level.vi。读取温度后通知UI。这里不将Send Update Temperature的错误输出连接到error out,是为了程序在没有UI的时候也能正常运行。
2.
Set Output State.vi。设置读取后温度,经逻辑处理,输出为水泵的状态。也要通知给UI。Send Update Pump的错误输出端也没有连,原因你懂的。
3.
Update Fan Status.vi。更新风扇状态。这个有点小曲折。因为UI和Cooler平起平坐(关联),Dual Fan是由Cooler启动的,Dual Fan和UI之间没法交流。所以只好在Cooler中写个public的Update Fan Status.vi,并为他创建消息,这样Dual Fan的状态就会通过Cooler传给UI。也就是Dual Fan状态改变时,要先给Cooler发消息,由于Cooler知道UI的队列,Cooler收到消息后会向UI发消息。