Guidance on G Interfaces

[reniam]

Hi,

I'm intrigued by interfaces as we have been fighting the “fragile base class” problem discussed in the interfaces presentation and am looking for some feedback. Unfortunately, I have no practical experience with them so am struggling as to what/where an interface fits on the diagram. Please see the attached picture for my example.

In the diagram are three different types of instruments all using GPIB for communication. Does it make sense that the interface be GPIB as diagramed, or does it make more sense that the Abstract Layers be interfaces and the instruments inherit from GPIB? Since the interface doesn't have data, should the concrete implementations hold the GPIB data such as the ibsta Boolean array?

Thanks!

 

[tyk007]

Caveat - this is my personal opinion.

Interfaces are intended to express some contract for behavior - generally represented by method calls. The contract is determined by the code that will call the object implementing that interface. Interfaces offer the advantage that an object can implement more than one of them - which means that object can be treated as any one of its different interface 'facets'.

If this sounds similar to multiple inheritance, its because it is. The only difference (conceptually) between interface implementation and traditional multiple inheritance is that there is no object data in play which reduces one area of potential conflict.

The question you have to ask yourself is pretty much the same as with inheritance:

• Are you sharing a common contract between classes? So that a caller can treat the device objects the same in some way.
• Or are you sharing functionality? So while the device object contracts differ, there is some internal logic that is replicated in each.

The former lends to interfaces / inheritance. The latter lends to composition (eg delegating to a common GPIB class implementation). 

Personally I have encountered a few minor issues with the 2020 'f0' Interface implementation so am leaving adoption for another rev or two.

[reniam]

Thanks tyk007,

Just for future understanding, I've been through most of the literature available from NI for understanding. I get the concepts, but am having a block with real implementation.

The problem I came across is, when using GPIB as the abstract layer, the concrete implementations wouldn't be grouped together logically. My "Temperature" class has private data and methods for temperature soaking that is common to all temperature instruments. That code would now have to be implemented on each instrument class. Maybe that's OK and plunk it in a library, but then I'd lose polymorphism. My Temperature.lvclass "Soak.vi" couldn't be used in all the temperature instruments. Maybe that's best practice. I don't know.

[tyk007]

---

@reniam wrote:

The problem I came across is, when using GPIB as the abstract layer, the concrete implementations wouldn't be grouped together logically. 

---

That pretty much tells you that the concrete implementations don't have an "is-a" relationship with GPIB. That doesn't mean they can't access GPIB-specific functionality through composition "has-a".

If there are aspects that are common between them that's a candidate for a base-class implementation.

Its hard to be any more specific without something concrete (aka code) to work through. But generally, thinking in terms of objects and inheritance should be about implementing behavior, not nouns. 

[wiebe@CARYA]

---

@tyk007 wrote:

---

@reniam wrote:

The problem I came across is, when using GPIB as the abstract layer, the concrete implementations wouldn't be grouped together logically. 

---

That pretty much tells you that the concrete implementations don't have an "is-a" relationship with GPIB. That doesn't mean they can't access GPIB-specific functionality through composition "has-a".

---

I think that's spot on.

A device either has an interface (containment) or uses an interface (as an input).

Trying to make a device 'be' an interface will be hard. If it doesn't work in English, it usually doesn't work in OO.

The fact that GPIB is an interface (to hardware) does not make it a good OO interface to a device.

You can make an "HW interface" interface of course. Then make a GPIB class, a RS232 class, a TCP\IP class that implement the interface. Make each device use it (as an input), or contain it (in it's private data).

[crossrulz]

---

wiebe@CARYA wrote:

You can make an "HW interface" interface of course. Then make a GPIB class, a RS232 class, a TCP\IP class that implement the interface. Make each device use it (as an input), or contain it (in it's private data).

---

It's called VISA.  It is already done for you.

Back to the OP...Why do you need to implement a GPIB Instrument interface?  To me, it seems like you are going about it up-side-down.  I have a library (not a class) that handles commonly needed VISA actions.  It is almost all initialization stuff.  But then I have another library that handles common SCPI commands such as "reset", "get errors", etc.  My instruments that communicate over serial, GPIB, Ethernet, or USB (classes) all use those two libraries.

[wiebe@CARYA]

---

@crossrulz wrote:

---

wiebe@CARYA wrote:

You can make an "HW interface" interface of course. Then make a GPIB class, a RS232 class, a TCP\IP class that implement the interface. Make each device use it (as an input), or contain it (in it's private data).

---

It's called VISA.  It is already done for you.

---

I'd still put the general VISA stuff in a parent class, and specifics in GPIB, RS232, TCP\IP child, even though it's probably just the formatting of the VISA resource that will end up in the childs.

That will make it easier to do stuff like adding a simulation child, and a composite child that can contain a real interface and a logging interface... 

[reniam]

Back to the OP...Why do you need to implement a GPIB Instrument interface?  

---

Because I want it to be one of the concrete implementations of a generic "comm interface" in the ancestor class (instrument) because all instruments have one. To exploit the advantages of OOP.

I have a library (not a class) that handles commonly needed VISA actions.  It is almost all initialization stuff.  But then I have another library that handles common SCPI commands such as "reset", "get errors", etc.  My instruments that communicate over serial, GPIB, Ethernet, or USB (classes) all use those two libraries.

---

Sure, of course. I've had libraries like for over 25 years. This is trying to create hierarchical objects, attempting to create a software model of real things. G-interfaces promise to make this easier... somehow. I'm still trying to wrap my head around it and was hoping someone had insight.

[reniam]

---

---

I'd still put the general VISA stuff in a parent class, and specifics in GPIB, RS232, TCP\IP child, even though it's probably just the formatting of the VISA resource that will end up in the childs.

That will make it easier to do stuff like adding a simulation child, and a composite child that can contain a real interface and a logging interface... 

---

Yeah, that's what I'm coming up with. The ancestor class (instrument) has Name, Identification, Calibration, Measurement Type, Setpoint, Measurement Initialize and "Comm Interface" G-interface. This is what I've identified as common to any instrument. 

I prefer Comm Interface to HW Interface, since we're dealing with protocols. It has a contract for  "Write", "Read" so far. Maybe Initialize. The concreate implementations of GPIB, VISA, etc. 

[tyk007]

---

@reniam wrote:

---

Sure, of course. I've had libraries like for over 25 years. This is trying to create hierarchical objects, attempting to create a software model of real things. G-interfaces promise to make this easier... somehow. I'm still trying to wrap my head around it and was hoping someone had insight.

---

For what it's worth, I don't think object oriented programming (and, by extension, interfaces) is about modelling real things. Its about modelling behaviours in a system. In some cases they are "real" things (and that does happen a lot with implicit hardware-based designs) but frequently they are not. We tend to model behaviours, and abstractions, around changes we expect to happen in the system. When i create a model, my thought pattern includes "What changes might occur in the system? How will I reduce the scope of those changes on my design?"

Forgive the presumption, but I am wondering whether this discussion is not really specific to interfaces, but rather to modelling and determining an object-based design. Interfaces provide more options to assist with developing that design (in terms of exposing multiple contracts that make that object appear to be many things at once) but are just a tool to improve the ability to better model systems.

In case you haven't seen it - here is a link to an example that might help the Interface side of things (LabVIEW G Interfaces solving a decade old problem - Boring Engineer).