Factory Pattern - Wrong Thinking

[PaulOfElora]

Still struggling with the Plugin/Factory Pattern.  I made a simple little demo.  I have 4 levels in my class hierarchy: "Controller Class", parent of "Motion Controller Class", parent of "Stepper Motor Controller Class", parent of finally "DMC-30017 Motion".  So I use "Get LV Class Default Value VI" to load the grandchild class data into memory.  Then I try to "build up" from the "bottom" to a complete COntroller Class.  Then I try to coerce to type, just so can have 2 identical class objects with different names - they later take on unique identities.  But alas, I can't get the dreaded 'class conflict' compile error to go away.  Any light you can shed I would much appreciate - paul

[Kevin_Price]

You're still doing it.  You have a cascade of "to more SPECIFIC" function calls while attempting to cast to ever-more-generic (closer to the root) classes.  You really need to get your thinking straight on this sooner not later.

Having said that, I'm not sure that changing to the "to more GENERIC" function call is going to fix everything for you.  But for sure, the use of "to more specific" while actually trying to cast to more generic reveals some wrong thinking that also needs to be fixed.

-Kevin P

[crossrulz]

You only need to use the "To More Specific Class" once to set it to the generic controller.  The value on the wire will still know the object is still the type you initially loaded using the path.  I'm not sure why you are trying to use Coerce To Type.  If you want more specific API, you use To More Specific Class.

[Yamaeda]

Also, why do you want to specify a parent class, do you have some method in a parent you want to use instead of the Childs method?

[PaulOfElora]

Yeah, I'm really struggling to understand this.  I thought I was imitating the Factory Pattern stuff I've seen, but I'm mangling it...

[PaulOfElora]

Got it, thanks.  I used the Coerce To Type to duplicate the class object, then give the 2 unique names for later use.

[PaulOfElora]

Yamaeda - no, just imitating Factory Pattern examples

[crossrulz]

---

@PaulOfElora wrote:

Got it, thanks.  I used the Coerce To Type to duplicate the class object, then give the 2 unique names for later use.

---

LabVIEW OOP is by-value.  So if you fork the wire, you have created copies of the object.

[PaulOfElora]

Was reading 101 posts yesterday about this, but can't put my finger on it now, have to paraphrase.  Something clicked with me when I read that 1) First we bring a child class into memory using Get LV Class Default Value.  Now we have the child in memory, but the compiler knows nothing about its parent or entire class hierarchy, so it's not useful.  So we need to 2) Use To More Specific Class to tell the compiler that Child X 'belongs' to Parent Y.

LabVIEW Wiki states "This is done by providing the absolute path to a child class to Get LV Class Default Value, which will load the class into memory and return an object of that class as a generic LabVIEW object. This generic object can then be cast into the more specific parent class."

Elijah K states in his Patterns blurb "Factory Pattern - Provide a way to initialize the value on a parent wire with data from many different child classes based on some input value, such as a selector ring value, enum, or string input."

The TMSC Help states "Typecasts a reference, such as a control or a type definition, to a more specific class in the inheritance hierarchy."  I think this is where I get confused.  The Factory Pattern examples all show the child class being brought into memory by Get LV Class Default Value, then wired to the Reference input.  The Parent Class object constant is wired to the Target Class input.

Ahhhh - "...the value on a parent wire..."  I can feel some neurons lighting up a little as I write all this down.  1,000 thanks for y'all's attempts to help me get thru this particular fog...

[Kevin_Price]

...and in the interests of clarity, let me amend my prior remarks.

I was focused on the successive chain of "to more specific" calls that were primarily navigating themselves up your class hierarchy in a more *generic* way.   That part remains a wrong way of thinking, but it's also kind of a moot point at the immediate moment.

The reason is that you don't need to work your way incrementally over the hierarchy in *either* direction here.  This is what others have been saying, including the tutorials you quoted.

I was overlooking the part at very beginning of that chain where you load up the child class and the function returns the child object "in disguise" as a completely generic LVObject.  The LVObject class is the top-most root-level ancestor to every possible class in LVOOP.

So at that particular point in the chain, you should indeed use "to more specific".  But you can use it to cast straight to the final parent class without the chain of incremental steps in between.

Hopefully this helps you connect some more of the dots...

-Kevin P