oop_class_pro_con

[giscus[bot]]

类的优缺点

https://lv.qizhen.xyz/oop_class_pro_con

[Arita9527]

类拖到后面板上时：
1.颜色和什么有关？
2.为啥有些有三个小圆点？
谢谢

[ruanqizhen]

这是类的图标，类似于子VI可以有自己的图标。在类的设置对话框里可以设置类的图标，与设置VI图标方法相似。

[swordscan]

子类加载了，父类也加载，倒是可以接受，比较反人类的是sibling的类也加载了，这个就很难受了。而且一个类树里，如果某个vi broken了，类树中其它类同名vi也会broken，这真是让人绝望了

[wyongjian]

只要保证提供给用胡的 API 不变，底层结构怎么更新都没事。

[wyongjian]

这里用户是个错别字

[ruanqizhen]

已修改

[gitliuyawen]

"但一个夫类并不会知道他有多少个子类",最后一个标题，《LVClass 内存加载引发的类型转换问题》，倒数第2行。父类与夫类，老板用的是五笔打字吗？还

[ruanqizhen]

拼音。已经修改。

[metachow]

首先要感谢博主写的这本介绍LabVIEW编程的书并慷慨地把这本书分享到互联网上。我大概是用两年多前开始接触LabVIEW并尝试用LabVIEW编写自己的应用程序，这本书给了我很大的帮助，同时我也觉得有一本母语写的LabVIEW技术书籍是一种幸运。直到现在我也会在编程的时候偶尔打开这个网站，查漏补缺，常看常新。

当我在使用LVOOP来抽象复用我的仪器控制代码的时候，LVOOP的传值语义给我挖了不小的坑。因为在这之前我已经频繁地使用通知器，队列，以及DAQmx，所以我本能地以为当我在一个线程对实例成员数据进行操作之后，另一个线程的实例也会更新。后面我debug的时候才发线如果从实例分叉成两条线，值也会复制成两份。这个行为和普通编程语言有很大的不同，普通编程语言只要拿到实例的句柄就可以在任意位置改变实例的状态，但是LabVIEW显然不是这样。

如果要在LabVIEW的类里面实现引用语义，要么就是像LabVIEW示例里面推荐的那样，用一个单元素队列来存储和更新私有成员，要么是为私有数据套一层DVR，用in-place结构来读写私有数据，再或者把整个程序设计成actor框架，用队列消息来在不同线程之间传递数据。但是这些方法会导致代码非常啰嗦，程序的结构性开销严重膨胀。

后面我查看NI的论坛，发现很多人对LabVIEW的OOP也颇有微词。在复杂工程中，开发者几乎必然要借助 DVR、FGV 或 Actor 框架来恢复引用语义，这让很多代码结构显得笨重，以至于有数个LabVIEW第三方库用以实现传引用语义的OOP。虽然说LabVIEW这样设计的本意是为了安全考虑，但是对已经接触到LabVIEW类这个级别的开发者来说，竞态条件这些应该都已经十分清楚了，个人感觉LVOOP完全没有必要设计成传值语义，一不直观，二不简洁。不同的LabVIEW模块之间也缺乏一个一致的范式，一会像普通代码一样传值，另一会又像队列那样传引用。很想知道博主对于这个问题有什么看法，平时在LabVIEW编程的时候如何实现跨线程对同一个对象的操作，以后NI在这一点上面有没有可能做出一定的改进，还是会继续作为LabVIEW历史遗留问题的一部分？

[ruanqizhen]

非常感谢你分享自己的想法。

我已经有很多年没有在实际项目中使用 LabVIEW 进行开发了，因此以下内容仅是我基于过往经验所做的一些个人观察。

在面向对象编程的实现上，LabVIEW 似乎更多的借鉴了 C++ 的设计思路。C++ 中的 class 本质上是对 struct 的扩展，它同样采用值语义作为默认的对象传递方式。当需要引用语义时，必须显式地使用引用或指针。而 LabVIEW 的 Class 可以视作对 cluster 的扩展，因此也沿用了 cluster 的数据流模型和默认的值传递机制。这种设计选择既保持了 LabVIEW 一贯的数据流一致性，也简化了开发难度，同时避免了引用语义可能带来的并行冲突和内存管理复杂性。

代价是，LabVIEW 程序员在某些时候会觉得不方便，编程过程更加繁琐。

据说，NI 公司曾经探讨过在 LabVIEW 中引入更为便捷的“传引用”机制，以便在大型项目中减少数据复制、提升性能与内存利用效率。但似乎，相对于完善编程语言本身， NI 公司更重视 LabVIEW与硬件生态的深度集成（如 PXI、CompactRIO）、实时控制系统的支持（RTOS + FPGA）、以及测控自动化领域的可靠性与易用性等等方面。

我估计，NI 公司将来也会继续延续这样的策略，不会对 LabVIEW 语言本身做太大的改动。