Is having a 'VISA' class too vague to be useful? (OOP)

[Shiv0921]

My application speaks to 8 different RS232 instruments and I'm not sure if I'm going too far in saying that's common functionality.

I've been thinking of having a VISA parent class to define holding the settings, configuring the port, closing the port, some kind of error reaction.

Next child down (Simple VISA) having a 'write' and 'read' for the instruments that I only need single command write and read response control of. This is the abstract class I'd put through my test VIs and swap simple read/write instruments into. 

Some of the others need to be able to have more granular control, so would inherit directly from VISA parent and define their own specific functions. (write x, write y, read z) rather than having singular 'write' and 'read' methods.

Is this sane? Examples for HALs I've seen set the abstract class at the type of instrument (power supply, multimeter etc) rather than as broad as the type of comms. Wondering if I'm looking at commonality that's unnecessary?

Something like this diagram (apologies for jankiness) 

...Especially if I then wanted to also have the HAL, which would have me adding that lowest layer where I do then sperate by instrument type. Perhaps this is where my straw man of starting as high as the comms type falls down? It feels smelly but I can't place why and I have a lot of applications like this so I'd like to pin down whether this isn't good.

[Shiv0921]

Okay second thought. Maybe the issue isn't so much the VISA class as bothering to have the 'simple serial' class. I could take that out and just have a regular set of HAL classes, all of which inherit from VISA . so it's just an extra parent on top of the normal HAL examples that covers the VISA commonality?

Again sorry that the diagram isn't an actual class diagram.

Feels cleaner, but takes away my option to use the simple serial parent class to run through my 'Config/Write/Read/Close' test VI, which would have been nice given that for 4 of the instruments that's all I need to check. 

[crossrulz · Accepted solution]

I would not make it a VISA Class simply because I run into too many instruments that do not use VISA.  It makes more sense to me to have a Power Supply class as the main parent and then a SCPI Power Supply class that uses VISA and other power supplies that are slightly different can inherit from.

So instead of having a VISA class, I just have a VISA library that can be reused by anything.

[Yamaeda]

What happens when you get a new PSU with a different connection, as TCP/IP?

[Shiv0921]

Ahhh that makes sense. Because power supplies of a variety of different communication types will have more common methods than a bunch of serial instruments of different types, so more useful to have the power supply class. Thank you! 

[Intaris · Accepted solution]

---

@Shiv0921 wrote:

Ahhh that makes sense. Because power supplies of a variety of different communication types will have more common methods than a bunch of serial instruments of different types, so more useful to have the power supply class. Thank you! 

---

Yes, i think you have the wrong approach.

Define a device class independent of the communication method.

Then add a class for "communication" which has a completely different inheritance tree to the device. Then you can implement read / write and whatever else you need in the communication class and simply swap it our to change a device from being controlled via serial to being controlled via TCP/IP.

This is a classic "Composition" vs "inheritance" issue. If you "ARE" the thing, inheritance might work. If, however, "USE" the thing, then use composition. For example, you could have a VISA class, and then have VISA TCP and VISA Serial as children. They are all essentially the same thing, so inheritance here might make sense

A child should "BE" the same kind of thing as it's parent. Your devices are NOT communication protocols, they are devices that USE a protocol. Therefore, put the protocol as a field of the private data of the device for it to use. Don't inherit from it.

[Shiv0921]

Ohhhhhhh of course. Thank you for breaking it down like that. I'd sort of forgotten composition was an option, and to analyze with 'IS' vs 'USES'. I think I need to refresh myself on some of these distinctions for doing the rest of my planning. Thanks for laying it out!

[Kyle97330]

You've already marked as solved, but if you come back here or anyone searches for this...

If you have LabVIEW 2020 or later, then the OOP hierarchy supports "Interfaces" as well as standard inheritance.

The best way to manage this is probably to use "Power supply" as a parent, possibly with a more generic "Device" as a grandparent, and then create an "Interface" for any connection type.  You could create a Serial interface to set baud rates, an Ethernet interface to set the IP address and ping it, and so on.

So basically, anything "IS" is standard inheritance, anything "USES" is an interface.