Super basic Factory Pattern question

[Yamaeda]

---

@PaulOfElora wrote:

Thanks, Yamaeda (again) for helping me un-overthink this! I kinda thought that i needed the aircraft carrier when only the propeller was needed... paul

---

I know where you're coming from. 🙂 I was very much the same way when it first came to objects or events or queues.

"But how does it work, how do i tap into and know where this X is coming from?", and the answer is: "Don't worry, the system/framework handles that, just create the reference and let the FW work." 🙂

[PaulOfElora]

Thanks again for our help, wiebe.  Yes, at the rate I'm going, I'll get somewhere fast (just might not be the best place!😋).  Of course, usually "going fast" means "going off course".  But oh well, I do have to get this system up and running, and the boss says he wants HAL-ish flexibility, so here goes... Unfortunately, these days I'm the only LabVIEW programmer in the division, so no mentors or people to bounce things off.  You guys are it!

[PaulOfElora]

LOL - I started my 1st programming in oh 1977 or so, standing in line in front of the punch card reader at midnight, praying that my Fortran assignment would compile... For my elderly neurons, this has been a great workout, rewinding to 1977 and basically starting over!  It's all good!  Thanks $10^6 for your help! paul

[BertMcMahan · Accepted solution]

So just FYI, you don't have to do the whole "Get default class data" route if you don't want to or if it's confusing. You can skip that for now and come back later when it "clicks".

If your inheritance structure isn't very big, just drop a class constant for each child class in a different case of your case structure. LV will automatically cast all inputs to their highest common ancestor.

The downside is that your project has to refer to ALL of the classes (since a BD constant will load the class into the project, and it's not as scalable) but it's simpler to do for small projects that don't need complicated plugins or changes down the line.

[Jacobson-ni]

---

@BertMcMahan wrote:

The downside is that your project has to refer to ALL of the classes (since a BD constant will load the class into the project, and it's not as scalable) but it's simpler to do for small projects that don't need complicated plugins or changes down the line.

---

If you are going to go down that route you will also want to make sure you aren't depending on too many drivers by doing this. This is a fine approach if everything is pure LabVIEW but I've seen people run into issues when they try to get this code running on another system and need to download 4+ drivers that they won't be using to get things working.

[BertMcMahan]

Excellent point.

[PaulOfElora]

Ahhh, that's good advice, Bert, thanks.  Yeah, actually, since this is such a "static" HAL situation, I think static class objects will be just fine.  If/when somebody in the future needs to replace the types of devices, they'll be needing to do some coding for sure, if nothing else, to write code that fits my "API".  I just want to make it as easy & straightforward as possible for that possibility.  I mean, I'm still using lots of dynamic dispatching, but in a "static sort of way", nothing fancy like the XML configuration schemes that I've seen.  Much obliged for all your help as usual, STAY HEALTHY! paul

[PaulOfElora]

Thanks Matt, I guess I could see that turning into a nightmare.  Actually, I am using pure LabVIEW - all the stuff I'm talking to is running off of TCP - strings out, strings back.  And things pretty much have to stay that, since it's a remote application.  STAY HEALTHY! paul

[wiebe@CARYA]

---

@BertMcMahan wrote:

The downside is that your project has to refer to ALL of the classes (since a BD constant will load the class into the project, and it's not as scalable) but it's simpler to do for small projects that don't need complicated plugins or changes down the line.

---

If you pick your dynamic class at run time, all classes need to be in memory anyway. If they are instantiated by path\name, when you build an executable, you can't load the classed, because they're included automatically. So you need to force them into the executable's memory some other way.

If you are using constants, all the classes that you can choose from at run time will be included in the executable, and that is 'care free'. For small and big projects...

It's not really about big or small projects, but about how you're going to use it.

Instead of a case structure to pick which (child) class to use, you can use a conditional disabled structure. You can make your own symbols, or use one of the build in symbols. That will get you a mix that can be nice: care free, without all classes being included in the executable. You can use this to pick a different class depending on RTE\dev., 32\64 bit, RT\PC, OS, etc.. Or use a pre-build script that sets symbols to different values depending on the build scripts.

[PaulOfElora]

Ahhh hadn't thought of that, Bert, gotta look into it, I haven't used that yet - thanks, paul