LVOOP - Pattern question

[AYanez]

Hi dear LV developers, I am replacing the logic in a program with LVOOP, but I am facing some doubts about if my solution follows good practices. I am attaching a demo of the code.

I have different classes to read data from different sources with inheritance (Reader Class), now I need to leave a hook to the software to implement N processing algorithms. Due the output of this method is fixed (To 1D array) I created a classes family for the algorithms to take advantage of dynamic dispatch (Calc method in my code)

If I describe the pattern is something like a mix between Command Pattern (Because I need to encapsulate different type of data before to execute the algorithm and the final method is to like a Do action) and a Decorator Pattern because I need a support class as input to retrieve the data (Reader Class Object) but one of the outputs of the method is the Reader object itself, the same that I passed as input, I did it because I need this method for other actions in the code I do not want to branch the wire.

Reader class has several children. After getting back my Reader object I observed that everything is ok with dynamic dispatch methods I understand that if I want to execute a specific method I would have to use Preserve Run Time Class but it is not intended purpose because Reader Class will be selected with a Factory Pattern in the application. After explaining my case I have the next questions:

Is OK to pass in and back to an object into a dynamic dispatch method? Like I am doing with the Reader object.

May I have issues in the future with this implementation?

Do you have a better solution for my scenario? I will be happy to read the opinions.

In case that in the future I will need to execute a specific instance of a Reader Children's the usage of Preserve Run Time Class is a valid one? I have not often seen the use of this primitive 🙂

Why is not there coercion in the output of the Calc method? I saw one for the input I think it is normal but how can LabVIEW know that the output belongs to a specific instance if the input was downgraded to the parent?

Thanks for the attention and sorry for too much text but I wanted to give a clear explanation 🙂

[crossrulz]

Admittedly, I just skimmed through your description.  But it sounds a lot like what you really want to use is the Actor Framework.

[AYanez]

Hi Crossrulz thanks for your answer, I admitted that I had a look into AF, but where I work many people dont know LVOOP yet, so AF would be very complex to maintain the code in the future, that is the reason because I want to keep it simple enough, is easier to understand dynamic dispatch than AF code. 

[wiebe@CARYA]

Sounds to me you made functor. But that is close enough to a command pattern. A decorator is usually part of the class (in it's private data). You can use patterns to communicate ideas, but you don't have to label everything. Things can be a bit of both, and in fact a lot of patterns look pretty much the same, except for the typical appliance.

---

@AYanez wrote:

Is OK to pass in and back to an object into a dynamic dispatch method? Like I am doing with the Reader object.

---

Sure. Nothing wrong with it. The output object that is not DD will still be the object you use for input. It's just that LabVIEW can't automatically detect the output type over the DD-ing of the other class.

---

@AYanez wrote:

May I have issues in the future with this implementation?

---

Worse case, you need a preserve runtime class every now and then.

It can be a problem though. If you have a codebase that uses a child, and that object goes into a static VI. The object type will be preserved. Then you change it to DD, and your code breaks at random places... Once you have that problem, it doesn't get worse.

---

@AYanez wrote:

 Do you have a better solution for my scenario? I will be happy to read the opinions. 

---

You've chosen to give the calculator class the reader class as an input. That's sounds a bit off. The reader should read, the calculator should calculate. Of course you'll have some contamination at times... It sounds to me you need a stand alone calculator class and reader class, and a third class to handle them. 

A data class might help (or just confuse things). The reader class can then produce data objects, that can be used in the calculator class. That separates the two classes.

---

@AYanez wrote:

 In case that in the future I will need to execute a specific instance of a Reader Children's the usage of Preserve Run Time Class is a valid one? I have not often seen the use of this primitive 🙂

---

If you need to call a specific reader child, I'd use a "to more specific", not a "preserve runtime class". Both would do the task, but I think the PRC is intended to hint the compiler that the output should be the input, so you don't get the automatic "to more generic" when the object goes through a VI.

If you need to call a method on a specific child in a sub VI, it might make sense to change the input of that VI to that specific class.

Or you can implement the method in the parent, so it works for the entire hierarchy but only does something for the specific child. That is only acceptable if it makes some sense, you don't want to keep adding methods to the parent to support all the different child methods. If that happens, decorators or even completely separated classes could be more suitable.

---

@AYanez wrote:

Why is not there coercion in the output of the Calc method? I saw one for the input I think it is normal but how can LabVIEW know that the output belongs to a specific instance if the input was downgraded to the parent?

---

 LabVIEW can sometimes detect and therefor keep the specific type. It detects if a class wire "flows through" a VI. If it does, you'll keep the specific input type on the output, even if it's a static parent type that is on the output. The moment the VI goes DD (, and IIRC there's more then one implementation), LabVIEW can't\won't do this anymore, and the output type is the hard coded output of the VI.

I'm not sure if you can ever get the specific type when there is a coercion dot on the input. Output\source coercion dots are quite rare in general.

Can't look at the code, as it's probably in a more recent LV version. Also, it will take even more time.