How deep is you inheritance tree?

[Antoine Chalons]

I have a class hierarchy that has 9 levels of inheritance, 78 classes in total and I probably will reach 100 classes at some point.

I have not really noticed any specific issue with this, project load time is similar to other project of similar size but with tiny inheritance trees.

The only issue I ran into is that if I mass compile from the project, it will take days but if I mass compile from the tools menu, just a few minutes. (see discussion on NI forums about this)

Edited November 10, 2022 by Antoine Chalons
actually 9, not 8

[crossrulz]

I might have a couple of classes floating around that hit 4 levels deep.  I would say well over 90% have 1 or 2 levels, so I voted based on the large majority.

Edited November 10, 2022 by crossrulz

[LogMAN]

Mine are between 1-3 levels

[Rolf Kalbermatter]

My own class hierarchies seldom go beyond 3. I try to keep it flat and with interfaces, which don't quite count as class, it is even easier. Usually I used to have a Base class that was pretty much nothing else than an interface, but before LabVIEW knew interfaces this was the best I could do. I also regularly put some common code in there, so strictly speaking it is an abstract class more than an interface but I digress.

A lot of my VI classes are in fact drivers to allow for different devices or hardware interfaces to be treated the same. For these you seldom end up having more than 3 or 4 hierarchy levels, including the base class (interface).

And then I use compositing a lot which doesn't really count as inheritance, so I don't count it here. If you would add that in, things would get a lot deeper as there are typically several levels of compositing.

In a project I have been helping on the sidelines and which I'm going to be working a lot more in the future, there are actually deeper levels sometimes. Some of them approach 9 levels easily nowadays. The system uses PPLs per class and loads them all dynamically. It works for Windows and NI Linux. Aside from the pretty well known issues about being very strict about never opening more than one project (each class/PPL needs its own project to work like this) and keeping the paths very strictly consistent (with symbolic links to map the current architecture tree of dependent packed libraries Windows/Linux into a common path) this works quite well. It's a pain in the ass if you try to take shortcuts and quickly do something here and there, but if you can keep to the process flow it actually works.

As long as you do this only for Windows, things are fairly simply. PPL loading on LabVIEW for Windows is fairly forgiving in many aspects. On NI Linux however things go awry fast and can get very ugly if you are not careful. The entire PPL handling on non-Windows platforms seems to have been only debugged to the point where it started to work, not where it really works reliably even if you don't follow the unwritten rules strictly.

For instance we noticed that if you rebuild a higher level PPL/class under Windows, LabVIEW will happily keep loading child classes that depend on this. Don't try to do that on NI Linux! LabVIEW will simply refuse to load the child class as it seems to remember that it depended on a different version of the parent than what is there now and simply bails out during load. So whenever you rebuild a higher level parent class, you need to also rebuild the entire dependency chain. The MGI Solution Explorer is an indispensable tool to keep this manageable.

Edited November 11, 2022 by Rolf Kalbermatter

[ShaunR]

I don't really use classes for the intended purposes. I mainly use them as a variable cluster local to the instance when I need to keep track of state (sessions, stateful protocols et. al.). On the rare occasions I have used them for the intended purposes it has never gone beyond 2-3 and it's always been more hassle than it's worth, less elegant and incomprehensible build times.

Edited November 11, 2022 by ShaunR

[MikaelH]

Mostly we use 3 levels for the instrument driver (InstrumentBase <- InstrumentType(e.g. PowerSupply) <- RealInstrumentDriver (but also a simulated type)
We currently have 398 classes in our instrument hierarchy, 60 different InstrumentTypes such as: (TemperatureControllers, Robots, WeldingLasers, GlueDispensers, StepperMotors)

 

[drjdpowell]

Messenger Library is 4 levels, so I answered 3-6, though my more common use of Classes will be 1-3.

Though I note that number of levels doesn't necessarily map directly on any meaningful measures of complexity, as it is easy to add additional parent levels that represent only simple capabilities.  My top-level Address class in Messenger Library is just "a thing one can send a message to", and primarily defines only a "Send" method.  It doesn't even define creation/destruction methods (those are in level two).   

Edited November 14, 2022 by drjdpowell

[drjdpowell]

On 11/11/2022 at 8:24 AM, LogMAN said:

Mine are between 1-3 levels

Is that not four levels?

[Antoine Chalons]

2 minutes ago, drjdpowell said:

Though I note that number of levels doesn't necessarily map directly on any meaningful measures of complexity

I fully agree with that, my use case is in fact quite simple and over-uses abstract classes in some occasions.

[Antoine Chalons]

4 minutes ago, drjdpowell said:

Is that not four levels?

neer-impossible to tell as the image resolution is too low

[LogMAN]

1 hour ago, drjdpowell said:

Is that not four levels?

It's three at the deepest level, not counting LabVIEW Object. The class browser arranges some classes wrong, which makes it look like there are extra levels.

[Bryan]

I never necessarily had a defined depth limit in my mind of how many levels I would deem too be overkill.  For my uses, 1-3 just always seemed to be where it ended for me.

[jcarmody]

2 hours ago, drjdpowell said:

it is easy to add additional parent levels that represent only simple capabilities

Please forgive the intrusion as I'm neither of the "A"s* in "LAVA", but I just finished the NI OO class (and slept in a Holiday Inn last night) and wonder if that's not something I could use interfaces for.

* neither Advanced nor Architect

[drjdpowell]

7 minutes ago, jcarmody said:

Please forgive the intrusion as I'm neither of the "A"s* in "LAVA", but I just finished the NI OO class (and slept in a Holiday Inn last night) and wonder if that's not something I could use interfaces for.

Yes, the new Interfaces will takeover much of the work previously done with abstract parent classes.  

[Rolf Kalbermatter]

19 hours ago, drjdpowell said:

Yes, the new Interfaces will takeover much of the work previously done with abstract parent classes.  

Just to be clearer here. In Java you have actually three types of classes (interfaces, abstract classes and normal classes).

Interfaces are like LabVIEW interfaces, they define the method interface but have no other code components. A derived class MUST implement an override for every method defined in an interface.

Normal classes are the opposite, all their methods are fully implemented, but might be empty do nothings sometimes if the developer expects them to be overwritten. 

Abstract classes are classes that are a bit of both. They implement methods but also have method interfaces definitions that a derived class MUST override.

If you have a LabVIEW class that has some of its methods designated with the "Must override" checkbox you have in fact the same as what Java abstract classes are, but not quite. In Java, abstract classes can't be instantiated, just as interfaces can't be instantiated, because some (or all) of their methods are simply not present. LabVIEW "abstract" classes are fully instantiable, since there is an actual method implementation for every method, even if it is usually empty for "Must override" methods.

[drjdpowell]

3 hours ago, Rolf Kalbermatter said:

Interfaces are like LabVIEW interfaces, they define the method interface but have no other code components. A derived class MUST implement an override for every method defined in an interface.

I haven't used them yet, but I thought LabVIEW Interfaces are like LabVIEW Classes, just with no private data.  

[Rolf Kalbermatter]

11 minutes ago, drjdpowell said:

I haven't used them yet, but I thought LabVIEW Interfaces are like LabVIEW Classes, just with no private data.  

I have to admit that I didn't use them either, yet! And you could be right about that. They definitely need a VI for each method as there is no such thing as a LabVIEW front panel only VI (at least for official non NI developers 🙂 ). I would expect them to be however all at least set to "Must Override" by default, if it is even an option to disable that.

[LogMAN]

Further reading: LabVIEW Interfaces: The Decisions Behind the Design - NI Community

[Aristos Queue]

Talking G code here only... I don't have a particular max, but most of mine are depth 2 to 4. I've had one get to six. I've had deeper in some other languages.

The average depth is shallower these days with interfaces.