LVOOP Accessor vs. Property Node

[Nathan_S]

So I just passed my CLD and am trying to explore the world of LVOOP.  I'm a Mechanical Engineer with about 1.5 years of experience in LabVIEW, so I still have a ton to learn.

While browsing through LVOOP, I've run across some things I can't seem to reconcile. 

When is the proper time to create an Accessor method for a property of a class and when is the proper time to just use a Property Node to get or set a piece of class information?

Does child class data need to have the entire set of parent data instantiated in it plus its own?  Or does it just have its own data?  (i.e., if parent has Name and Value, does child need Name, Value, and Amount or just Amount?)

Can someone provide an example of using Composition as a class relationship?  I understand from the LVOOP training class that Composition is a "has-a" relationship, but I am still unsure what that actually means in the real world. 

Any help is appreciated.  Thanks

[Thoric]

Firstly, well done on passing your CLD.

Secondly, I'm no expert in OOP, but let me try to offer some help:

---

When is the proper time to create an Accessor method for a property of a class and when is the proper time to just use a Property Node to get or set a piece of class information?

---

As far as I know, you can create an Accessor without making it available as a Property Node, but not vica versa. When you choose to make it available through a Property Node is up to you. There are block diagram real-estate advantages to be had when using a stacked property node primitive.

---

Does child class data need to have the entire set of parent data instantiated in it plus its own?  Or does it just have its own data?  (i.e., if parent has Name and Value, does child need Name, Value, and Amount or just Amount?)

---

I think, by definition, a child class will inherit the same private data definition as the parent, plus its own. But you don't need to create new child class accessors to these parent data elements, you can call the parent class accessor VIs. Therefore, in your example, the child class just needs an Amount accessor VI for read and another for Write.

---

Can someone provide an example of using Composition as a class relationship?  I understand from the LVOOP training class that Composition is a "has-a" relationship, but I am still unsure what that actually means in the real world.

---

In this link, TheMadScientist discusses how to apply the Composition Pattern to a Starbuzz coffee and condiments example.
Also, see here.

[SimonH · Accepted solution]

Welcome to the Object Oriented approach.

---

When is the proper time to create an Accessor method for a property of a class and when is the proper time to just use a Property Node to get or set a piece of class information?

---

I'm in the habit of always creating accessors and it's good practice to do so. Technically if the accessor was private (meaning no VI outside the class can call it), and you don't need to do any range checking or other logic on a read or a write, and your class doesn't have any children, then you could get away with just using an Unbundle By Name (using a property node requires creating an accessor - the property node is just syntactic sugar for calling the accessor).

An accessor allows you to:

1. set access scope (i.e. who is able to access that data, since class data is always private in LabVIEW)
2. centralize error checking or conversion code
3. protect code from changes to how you store a value (as long as you can write an accessor that returns a given value in the stated format, how the value is stored internal to the class will not affect the rest of the application)
4. have a single point to debug

---

Does child class data need to have the entire set of parent data instantiated in it plus its own?  Or does it just have its own data?  (i.e., if parent has Name and Value, does child need Name, Value, and Amount or just Amount?)

---

Not if you are using accessors to get at the parents data. Since the child inherits all the parents methods, it can call the parents accessor methods. Recreating the Name and Value fields for the child class would be exactly the type of duplicate work that OO seeks to avoid.

---

Can someone provide an example of using Composition as a class relationship?  I understand from the LVOOP training class that Composition is a "has-a" relationship, but I am still unsure what that actually means in the real world. 

---

Sure, take the DAQmx task model as an example.  A task class contains timing information and "has" one or more channels in it. Each channel could be it's own class that represents the type of measurement and scaling information for that particular channel.  Since the task class would contain an array of channel classes that have no use outside the context of a task then you have a composition relationship.

Hope this helps clear some things up,

Simon

[SimonH]

Looks like Thoric types a lot faster than I do -- I swear his answer wasn't there when I started.  I guess he does get a 6 hour head start being in the UK 

[Nathan_S]

haha, thanks to you both for the replies.  I understand it now.

[ohiofudu]

I will say concentrate on the basis of OOP Design which are Flexibility/modularity(inheritance) and Data protection(Encapsulation)there are good books to read on these OO principles.That said when you have your data Encapsulated(protected) you can now use Property to read and write.

[xubuli]

I have a follow up question for LabVIEW property:

For a class with a number of private data fields, the same number of properties can be created.

Q#1: When property values get changed, will private data values in the same class change?

Q#2: When property values get changed in child classes, will private data values in parent class change?

[crossrulz]

---

@xubuli wrote:

I have a follow up question for LabVIEW property:

For a class with a number of private data fields, the same number of properties can be created.

Q#1: When property values get changed, will private data values in the same class change?

Q#2: When property values get changed in child classes, will private data values in parent class change?

---

Your questioning feels like you are missing something important: the Property Node for a LVOOP class just calls the accessor method.  So if your method updates a private data value, the object's private data will get updated.  A child class cannot directly update private data in a parent class.  But it can use the accessor methods supplied by the parent.

[BertMcMahan]

---

@crossrulz wrote:

---

---

Your questioning feels like you are missing something important: the Property Node for a LVOOP class just calls the accessor method.  So if your method updates a private data value, the object's private data will get updated.  A child class cannot directly update private data in a parent class.  But it can use the accessor methods supplied by the parent.

---

@xbuli, you can prove this to yourself pretty easily, create a property node to access a given parameter, then right click it and select "Open Accessor VI". It opens up your accessor- the property node just calls that VI. It just makes it look a little different on the block diagram.

One consequence to this is that you can make any VI appear in a property node, not just an "accessor". As long as it fits the property node format with the classes at the top, error nodes at the bottom, and one input or one output, it can do whatever the heck you want it to. It doesn't need to map to a specific piece of private data.

For example: you have a power supply object and you have a "Set voltage" method that sends a command to the supply to set the current voltage. That function isn't just writing a value with a Bundle By Name node (though it could), it's actually outputting something to the hardware. Similarly, a "Read current voltage" property node could be used to read the actual instantaneous output voltage of the power supply. In that case, it's not really acting as a traditional accessor at all- it's doing some instrument communication to read the value of the power supply.

Tl;dr: The property node format for classes is PURELY an alternate way to call subVI's.

[xubuli]

Thank you for the explanation. I just started adopting LVOOP, which is still not my favorite OOP language. 

A class usually has private data fields and properties, and methods to operate on data. To access data in the class method, one can unbundle private data from class wire or use property node to access properties. I believe the later one is more expensive, but see it a lot in example code. Any comments?