Set Child class with defaults

[JÞB]

Which is exactly why I said Use the System Configuration API to Identify the device (If the model name is unique it is fully automatic Else you do need and operator to determine which is what (Say the system requires 2 SMU's One is driving a 12Vdc the other 3.3 for logic  Alias's SMU12V and SMU3V3 Now who gives a rat if the SMU12V is a 2400 or a 2430 for that matter, why should the app care if its address is GPIB0::24::Instr or ASRL::5::Instr?  it is SMU12V

Your code might have a Dynamic Dispatch for INIT_SMU12V.vi (although the VISA PnP Project style driver abstracts that for us already based on Interface information from the VISA.I/O Session.instr Parent class!)  Or it might have a DD Child class for a 2400 vs a 2430 (Although the 2430 can provide additional functions a 2400 is satisfactory but our normal 2400 is out for calibration and we only had a 2430 lying about so we swapped it in as SMU12V)  Why would any of that information need to cause a change in code? the darned resource is in the system somewhere and wired with inputs and outputs from the set of Points [ A] to the set of Points [B] and no software can change that!  All we need to know is how SMU12V is addressed.  Once we identify What Address SMU12V maps to we set that resource's VISA Alias to "SMU12V" and the developer knows what function SMU12V provides.

What you are trying to do will simply break the code if the child changes function or I/O Session Class

So, the only reason you REALLY need a Child is for when you have that perfectly fine Yokogawa SMU stuck in between [A] and [B] and aliased as SMU12V

[Jals]

I think the challenge where I could not quite wrap my head around a few things.

I got the point to use device alias name so there is no problem with it to hide the addresses. 

The place I have problem with might have to do with the way how I structured the methods. ( and I don't mind rewriting it in the correct ways)

From your example, calling either 2400 or 2430 as SMU12V and call it good since they can both share the same set of method. 

My scenario is more like SMU12V is either 2400 or B2901A. So I set up child classes-methods for 2400 and B2901A separetely. Then wrap them in parent method in execution. So when I want to initlize the SMU12V object, I can setup a dynamic dispatch as INIT_SMU12V and switch between the 2 child class when either presents in the system? (did i follow your thought correctly?)

Or in my this specific case.

A 2651A for high current driving vs 2430 for high V driving. 

I name 2651 as SMU_HA, and 2430 as SMU_HV

The way I structure now is when I need to use 2651A, I select with enum for HA, it creates object from 2600 child-class, and modify the object's address parameter accordingly. Or likewise for 2430. (because if I don't do it, the object inherit parent parameter which is blank)

One way I see how I can prevent the exposure of the code is to make a dynamic dispatcher that only takes one parameter writes the address to object inside the method instead of reading the entire thing out and then write it in. 

thank you 

[wiebe@CARYA]

---

Jals wrote:

One way I see how I can prevent the exposure of the code is to make a dynamic dispatcher that only takes one parameter writes the address to object inside the method instead of reading the entire thing out and then write it in. 

---

Yes, exactly...

And you might consider to make a parent method that takes the enum, and outputs a child. This is usually called a factory. The caller has no business doing that kind of class related stuff.

[crossrulz]

---

wiebe@CARYA wrote:

The caller has no business doing that kind of class related stuff.

---

Fully agree here. I typically have a library to act as an interface to the parent class.  Part of that library will be an Initialize which creates the objects, no matter which child is supposed to be loaded.  As I have stated before, I determine which class to load based on a configuration file.  But you could also use an enum of the system configuration to figure it out.