What are your thoughts about this "double queued command"

[Ben]

---

@jarcTec wrote:

... I am just wondering if there is a "more elegant" way of accomplishing the same. ...

---

You could use a LVOOP class

[altenbach]

This coding style somehow reminds me of a Turducken. 😄

[jarcTek]

---

@Ben wrote:

 

You could use a LVOOP class

---

 Would you say that my implementation is appropriate for, say, the CLD?

[Mark_Yedinak]

While the variant is very convenient I would avoid overusing it. I generally try to only use it for a generic envelope type message. For message contents I prefer to use typedefed clusters. It makes the code much more readable. If you have defined messages and defined data for them then please do use a definition for the data. While variants are useful they also obfuscate the code. When a concrete definition is available it should be used.

[Ben]

---

@jarcTec wrote:

---

@Ben wrote:

 

You could use a LVOOP class

---

 Would you say that my implementation is appropriate for, say, the CLD?

---

Yes but keep in mind NI will never expect you to implement anything that complicated. if you chose to implement something like that you better have a very good story if you want to avoid the "Too compicated" feedback.

---

@Christian wrote:

---

This coding style somehow reminds me of a Turducken.

---

I believe in OOP that is called the Composition Pattern where a class is made up of one or more other classes that in turn are made up of other classes.

I'll try using the term Turducken Pattern the next time I am doing an analysis and see if anyone questions it.

Ben

[jarcTek]

---

@altenbach wrote:

This coding style somehow reminds me of a Turducken. 😄

---

haha, I had not heard about that dish but it sounds delicious, so I guess it was a compliment, haha.

[Ben]

---

@jarcTec wrote:

---

@altenbach wrote:

This coding style somehow reminds me of a Turducken. 😄

---

haha, I had not heard about that dish but it sounds delicious, so I guess it was a compliment, haha.

---

Speaking as casual observer of Christian's posting habits;

Christain will jump on you if you are clearly wrong.

He will resort to humor if there is nothing obviously wrong but looks like a platapus to him. And no a platypus is not used in the making of Turducken, yet.

Ben

[Ben]

I should probably expand on the platypus comment a bit.

In OOP there is a concept called "Coupling" that speak to the extent different part of of an application are tied together.

When they are tightly coupled, they can not be sepearted and smal changes to one part can and will affect the other part.

Loosely coupled implies the other extreme with "completely un-coupled" indicating they have no dependnce on each other.

The goal is to develop Loosely coupled appliations so that is is easy to maintain etc.

The code construct you posted, while in theory does not violate any LV rules, in a theortical sense is very tightly coupled. If you change what is happening at the recieving end of that queue you have to check the sender as well.

There is another pattern called the "Expert Pattern" that is used to assign responcibility in the event you have no other good reason. THe Expert pattern ask "who should know the details?". in the case of the code you posted you hae assigned the part of your app that pusshes those queue entries as the expert in how those operations are supposed to take place. If you step back and say (well whoever is getting Init should know how to Init its parts, then maybe the nexted command and parameter should not come from the sending end but should be part of whatever is getting Init.

I hope that helps more than it hurts,

Ben

[Mark_Yedinak]

---

@Ben wrote:

I should probably expand on the platypus comment a bit.

In OOP there is a concept called "Coupling" that speak to the extent different part of of an application are tied together.

---

One minor clarification. Coupling is not strictly an OOP concept. It applies to any software system that has multiple components. This is really a measure of how well the system has been modularized.

[jarcTek]

---

@Ben wrote:

I should probably expand on the platypus comment a bit.

In OOP there is a concept called "Coupling" that speak to the extent different part of of an application are tied together.

When they are tightly coupled, they can not be sepearted and smal changes to one part can and will affect the other part.

Loosely coupled implies the other extreme with "completely un-coupled" indicating they have no dependnce on each other.

The goal is to develop Loosely coupled appliations so that is is easy to maintain etc.

The code construct you posted, while in theory does not violate any LV rules, in a theortical sense is very tightly coupled. If you change what is happening at the receiving end of that queue you have to check the sender as well.

There is another pattern called the "Expert Pattern" that is used to assign responcibility in the event you have no other good reason. THe Expert pattern ask "who should know the details?". in the case of the code you posted you hae assigned the part of your app that pusshes those queue entries as the expert in how those operations are supposed to take place. If you step back and say (well whoever is getting Init should know how to Init its parts, then maybe the nexted command and parameter should not come from the sending end but should be part of whatever is getting Init.

---

Thank you Ben, it hurts a little but that is how one learns, right? I understand what you mean by decoupling each section of the implementation. Could you provide an example of the "Expert Pattern"? If I understand correctly, you are saying that the sending end should only push a command into the queue and then the receiving end should know everything it needs to know in order to execute it?. How would you go about sending time-varying "arguments" to the receiving end then?

Going back to Mark's comment about variants, would you recommend any changes to my last figure regarding variants and type defs?

Thank you!!!!