Monostate Design Pattern

[JacquesDeJager]

Hey everyone,

I'm interested in learning how to recreate the "Monostate Design Pattern" in LabVIEW.

However, I'm not sure if it's possible since LabVIEW doesn't seem to have the ability to make variables "static." Instead, I am aware that VI's can return the same variables when called repeatedly through FGV's.

I'm looking for any advice or thoughts on this topic.

Please keep in mind that this is just a learning exercise for me and not for any specific project.

Thank you!

[tst]

I was not familiar with this pattern, but a quick look (at this, for instance) seems to indicate it's not relevant to LV, primarily because in LV all objects are fully by value and LV doesn't have constructors.

If I understand it correctly, the idea behind the pattern is to have a class where you instantiate an object normally (let's say by calling new myclass()), but all those object then point to the same data, which has to be static. I understand that the main advantage of the pattern over a singleton has to do with syntax, which is different in LV anyway.

In LV, you instantiate a class simply by dropping a class constant, etc., so each instance will have its own data anyway. You can make the class VIs access global data (make sure it's private) and that will allow all instance to have the same values. If you don't write to it, it will also be immutable.

[wiebe@CARYA]

You'd get very similar behavior by using a private global in the class, instead of (or next to) it's private data.

Race conditions are a risk though.

A private FGV would also work...

A DVR would also work, but needs an init, and aren't great for debugging.

Debugging anything with state will be harder. Use with caution and in moderation.

[JacquesDeJager]

Thank you for everyone's feedback.

I appreciate it. 

I will definitely look into your suggestions.

[tst]

Incidentally, if all of your data is static, you could just use a library instead of a class. You would have to write all the VIs to read the values anyway, since you can't just create accessors.

If you do want to have a class, you can also just set the values as the default values of the class data cluster and only create reading accessors. I can't say I see the point, though. That said, I'm not sure what the point of the pattern in other languages is. Presumably, you could also just create functions which return specific values instead of having to instantiate objects.

[Yamaeda]

---

@JacquesDeJager wrote:

I'm interested in learning how to recreate the "Monostate Design Pattern" in LabVIEW.

However, I'm not sure if it's possible since LabVIEW doesn't seem to have the ability to make variables "static." Instead, I am aware that VI's can return the same variables when called repeatedly through FGV's.

---

G# supports static classes. And/or you can use Class attributes (as opposed to Object attributes). 

[wiebe@CARYA]

---

@Yamaeda wrote:

---

@JacquesDeJager wrote:

I'm interested in learning how to recreate the "Monostate Design Pattern" in LabVIEW.

However, I'm not sure if it's possible since LabVIEW doesn't seem to have the ability to make variables "static." Instead, I am aware that VI's can return the same variables when called repeatedly through FGV's.

---

G# supports static classes. And/or you can use Class attributes (as opposed to Object attributes). 

---

Could you elaborate?

I never heard about Class attributes vs Object attributes.

Is that a G# thing?

[Yamaeda]

---

wiebe@CARYA wrote: Could you elaborate?

I never heard about Class attributes vs Object attributes.

Is that a G# thing?

---

Yes, since G# implements C# design in G, it supports the normal Object attributes by reference and a Class attribute (by ref) that's a "Class family global". I've never used it actually.

This explains it way better than i can. 🙂

Class variable - Wikipedia

"In class-based, object-oriented programming, a class variable is a variable defined in a class of which a single copy exists, regardless of how many instances of the class exist.^{[1][2][3][4][5]}

A class variable is not an instance variable. It is a special type of class attribute (or class property, field, or data member). The same dichotomy between instance and class members applies to methods ("member functions") as well; a class may have both instance methods and class methods."

[thols]

A class attribute is essentially a global variable shared by all objects in the class. In my opinion, there is always a better design pattern than to use them.

[wiebe@CARYA]

---

@thols wrote:

A class attribute is essentially a global variable shared by all objects in the class. 

---

A private global variable (if you know what's good for you), but a global nonetheless.

---

@thols wrote:

 In my opinion, there is always a better design pattern than to use them.

---

I concur.

I avoid everything by reference if I can. But every now and then you run into something that simply is a reference (often some 'external' resource). The few times I have a by reference object, having both object as class attributes start to make sense, but never looked for a similar pattern in C++.