Jump to content

How deep is you inheritance tree?


How deep is you inheritance tree?  

31 members have voted

You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.

Recommended Posts

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 by Antoine Chalons
actually 9, not 8
Link to comment

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 by Rolf Kalbermatter
Link to comment

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 by ShaunR
Link to comment

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)


 

  • Like 1
Link to comment

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 by drjdpowell
Link to comment
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

Link to comment
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.  

Link to comment
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.

Link to comment
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.  

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.