Jump to content
GregFreeman

Can this architecture issue be solved with composition?

Recommended Posts

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 by GregFreeman

Share this post


Link to post
Share on other sites

You can make interfaces with malleable VIs ;)

Edited by smithd
  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

 

image.png.7640dc06f361e5f435f70c191637ed73.png

  • Like 2

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.