Can this architecture issue be solved with composition?

[GregFreeman]

Sorry for the ambiguous title...hard to convey the problem without description.

Right now I have an application that takes various measurements, but for now I'm going to focus on current. The issue is that there are many devices that can take current measurements, which our customer will swap out. But they don't necessarily have a parent/child relationship. Everything I think of screams to me "This would be easy with interfaces" but I'm really hoping there is some solution with composition. 

The application has a lot of situations where there is a power supply, but they may use a DVM to take the current measurement because they get better resolution on their results. There are other times they just use the current measurement the power supply reports. So, I thought about having a current measurement class that is composed of a "Source" object and a "Measurement" object. In some cases the Source and Measurement objects would both be a power supply. In other cases one may be a power supply and the other a DVM. But, I also want all my power supplies to inherit from BasePowerSupply and the DVM to inherit from BaseDVM. But if I want to do this and have either a power supply or a DVM be the measurement class, they both have to inherit from the same base class with a MeasureCurrent must-override method. However, as soon as I do this, if I want to create a a Source class, the BasePowerSupply can't inherit from it too. 

To me this just screams having an ICurrentMeasurable interface and an ISourceable interface that classes can implement. But alas, I cannot. So, any suggestions are appreciated. It just seems to me the more complex instruments get the more I really want interfaces to keep overlapping functionality required while avoiding coupling of unrelated devices through inheritance.

Edited March 22, 2019 by GregFreeman

[smithd]

You can make interfaces with malleable VIs

Edited March 23, 2019 by smithd

[JamesMc86]

Could you use an adaptor around the DVM that inherits from the desired abstract classes? That has been my solution to this problem in the past.

[Francois Normandin]

I agree with James. That could be achieved through composition and adding an abstraction layer. (Sink and Source in the diagram below)

 

[ShaunR]

If the DVM and power supply are SCPI compliant; you only need to change the address of the command you send.

[drjdpowell]

I know this is a OOP question, but there are other ways of addressing your problem that use "duck typing", such as Shaun's SCPI instruments.  In my case, there would probably be an "actor" somewhere that responds to requests for current readings, and any actor that responds to those same messages is capable of substituting for it.

[GregFreeman]

Thanks very much everyone. And I really appreciate the UML -- very helpful