How do I extend functionality of a child class from a factory pattern?

[Matt_AM]

Hey Fancy Folks.

Question: How do you extend the funcationality of a child class with a factory pattern setup?

Background: I’m new to OOP.  I wanted to create a Power Supply class that I can reuse and have the basic functions easy to use.  I created a parent class, “Power Supply 2.0” which is basically being used to dynamically dispatch common things I want (set voltage, current, PS output, init child). Those Vis are dynamically dispatched, so their child class can set them correctly.  All my child classes use the power supply manufacturer’s libraries so each “set X” will require its own unique VI. 

Where I’m at: I have created the parent class and have created the child classes for basic functionality.  I wanted to then create various Vis for my child classes to extend their functionality.  Problem comes during edit time.  The parent class, Power Supply 2.0, is the wire type that runs throughout the main program.  However, say I wanted to add in an error query to a child (such as TDK Lambda Genisis child class), how do I specifically create that and use it in the block diagram without having to wire the child class in at the start? 

Attached is a zip file containing a basic set up of the code.  The project can be found at …/Labview Projects\Project Base\Proj.  Once loaded you can see Main.vi in the project window.  There are no controls (there will be when implemented, this is just a proof of concept project to make sure I have things built correctly), so pop on into the back panel.  From there you should see this.

First, I would like to discuss the top chain of vis then I’ll circle back to talk about the bottom chain.  The subvi 2^nd from the left in both chains is the one in question.  It is meant to query the TDK Genisis power supply for faults.  Going into the top chain’s error query, you will see the following.

The parent class is casted into the proper child class via to more specific (not sure if this is required, the VISA is stored in the parent class).  Going into the bottom chain’s fault query, you will see the following.

The difference between these two is that I am using proper child class (TDK Genisis) in the bottom chain VS using the parent class (Power Supply 2.0) for the top. 

As someone who is new to OOP design in general, I’m not sure if I should be using the parent class in the child class’ private methods.  That feels wrong to me because I feel like I’m abusing the encapsulation idea.  The other idea I had was something I found by a post from QFang.  He had had his main vi do a to more specific of the child then put that in an error case statement, see image below.  I think that could work, but it feels like a lot of overhead and would be a nightmare to switch out if I brought code over to another station with a different power supply.

Any advice would be appreciated.

Thanks,

Matt

[BowenM]

With the factory pattern you generally have a parent class (interface class) that is either empty or has very limited functionality. This class is the one that exists in your project.  Then, at runtime child classes are dynamically loaded into memory as needed. What this means is that ANY functionality you want to have in the child class must have at least a shell dynamic dispatch vi in your parent (interface) class.  Without that it breaks the factory pattern because, as you pointed out, otherwise you need to call the child class directly.

My solution to this is generally to shell out all sub vis in the interface class, and then at that level generate an error.  If the child you've loaded doesn't contain the functionality it returns an error.

[JScherer]

I'm also fairly new to OOP, but I have the following thoughts:

1) As an example: If you have a generic method "Set Voltage.vi," and "Set Current.vi," in your Power Supply 2.0 class, then you can have "Set Voltage and Current.vi"as a generic method.

2) I don't see anything inherently wrong with using a parent method in a child class, eg "Close and ReINIT.vi" could be a step that you want to implement in a specific child. Functionally, it would dynamic dispatch back to the child class if necessary.

I find when I have OOP difficulties, it's typically because I've run into a coupling/cohesion issue. I find those are best solved by talking a walk, getting lunch, and going back to the problem with fresh eyes.

Edit:
I second BowenM: I would also suggest a relatively empty interface class.

[Matt_AM]

BowmenM,

Which pattern should I be using then?  I came across this which talks about the various patterns and how to implement them in LabVIEW.  I am struggling to figure out which one I should be using.  My gut said factory since I wanted to have a lot of basic stuff set up and easily be changed at start via an Enum.  My next two guess would be Specification  or Decorator.  

JScherer

1) I have a few of those already.  I can see having a voltage/current after the init to be useful.  Fewer blocks being dropped is nice.  I have a few "macros" (not sure if thats the proper term) that do that for me.  Basically they call the accessor method for the class' voltage then call the dynamic dispatched Power Supply Set voltage method.

2) It just feels off to me, I'm not sure if that's good OOP coding practice.  An example would be using polling in a while loop vs event driven for a user interface.  Sure they both can work, but polling a bunch of booleans to determine whats changed is a bit sloppy when you can drop an event loop.