From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

accessing child class data with parent class static accessor

Solved!
Go to solution

I am new to LVOOP. I am trying to create data accessors in the parent class (static) and use them in the child class. I don't need them to be dynamic becase the accessors are identical for child and parent. Is there a way to access data of a class without creating accessor for each class?

LVOOP.png

0 Kudos
Message 1 of 12
(5,641 Views)

Sorry to say, but no.

 

One of the OOP implementation limits in LabVIEW is that all data access is private to the class.

So even under a parent - child relation, the data is private to each class, no sharing between the parent and child.

So the only way to access a childs data is to make accessors.

I don't see the point in not making them dynamic in your example

0 Kudos
Message 2 of 12
(5,630 Views)

dkfire,

 

So then do I have to make dynamic accessors for parent and all children?

 

Why would I ever want to make any thing static? I guess the only use case is when you want to create a method that you know whill not change.

 

Why would I ever want to make an accessor static?

0 Kudos
Message 3 of 12
(5,620 Views)

The basic structure of the code in your original post seems reasonable (although I would probably change some of the I/O on the DD method, but that's not really relevant).

 

The main reason you would want to make a method static is to ensure that any child class which wants to use that method will go through your implementation. Making a method static (whether it's a simple accessor or not) will not allow the child class to override your method and write whatever it wants into the fields that you defined. It's basically a way to guarantee that the code will work as you designed it to work. I would say that the majority of simple accessors should be static.


___________________
Try to take over the world!
0 Kudos
Message 4 of 12
(5,599 Views)

tst,

 

I followed your post until your last sentence. My example shows static accessors created in the parent classes. When the children where implementing the static accessors they didn't actually write to the child class data so the method was using 0's to calculate the pay check.

 

I reworked the project and created dynamic accessors and methods for all classes and every thing worked as expected. However I had to create identical methods for all of the classes. Which didn't have any vi reuse but because everything was dynamic I only had to place the parent vi's and because they were dynamic which was the nice thing about LVOOP. 

 

I guess static accessors don't make sense to me.

0 Kudos
Message 5 of 12
(5,584 Views)

@LabVIEW1234 wrote:
When the children where implementing the static accessors they didn't actually write to the child class data so the method was using 0's to calculate the pay check.

I was actually wondering about that and forgot to ask about it. Now I understand.

 

The big problem in the sentence I quoted was "child class data" - if the rate, number of hours and resulting pay are something which are shared by all employees, then they don't belong in the children at all - you create them ONLY in the employee class and you use the static methods to write AND read them from the parent's data. LabVIEW makes sure that the each child has the parent data and that it correctly accesses it and if you wire a child into a VI it will automatically output a wire of the same type out of it. That way you get your reuse.

 

In this particular case, like I said, I might have gone with a different set of I/O on the paycheck method (e.g. it might have had at least number of hours as an input and the pay as an output and then you wouldn't necessarily keep the data at all in the object), but that's an implementation detail of the specific design, not something general.


___________________
Try to take over the world!
0 Kudos
Message 6 of 12
(5,577 Views)
Solution
Accepted by topic author LabVIEW1234

Untitled.png

 

This is the dynamic method that I created that finally works. Once I found the VI "Call Parent Method.vi" it all worked out.

 

So now I create all my data accessors as static and my methods are dynamic (assuming they need to be).

 

Thanks everyone for the help.

0 Kudos
Message 7 of 12
(5,525 Views)

There are no details in your screenshot, so I can't offer any real insights, but it certainly doesn't look right. Generally, you shouldn't have an enum for deciding what to do - that's exactly the point of having the hierarchy - the classes are the values of the enum and the dynamic dispatching VIs are the cases which are presumably inside that VI.

 

In your specific example, let's assume that there's a standard part to the paycheck calc (rate*hours*cert factor) and that then each additional level might have some additional logic. One way to write the code for that would be to have a static paycheck method in the parent (calc paycheck.vi), which is what the user actually calls. That method would perform the calculation (it would get the cert factor by calling a DD VI, where the BD of those VIs can simply have a constant wired to an indicator) and then feed the result into a DD VI (calc extra pay logic.vi) which will (or not, if it doesn't exist) add its own logic to the calculation. If the parent doesn't want the children to touch the previous calculation, then you change it so that the second VI outputs a value which the parent adds to the paycheck.

 

Of course, this is just one way in which you can do something like this. Choosing how to implement what you need ultimately falls on your shoulders as the designer of the classes.

 

 


___________________
Try to take over the world!
0 Kudos
Message 8 of 12
(5,512 Views)

tst,

 

Thanks you so much for the comments. I did this very late last night and really this DD Vi didn't have anything to do with paycheck. It was to show that I understand how to implement DD Vis.

 

The function of this DD Vi is called Hire. When a CLD or CLA is hired there job title needs to be set. Of course this is a perfect chance to use a DD Vi.

 

The child vi Hire in the CLD class does not inherit access to the employee class (parent) data. I used the "Call Parent Method Vi" to gain access to the Static Data Accessor. In this case I wrote "CLD" to the Job Title. So in an my main Vi I can call the DD Vi and it will remember the proper JobTitle.

 

My main problem in this whole exercise was understanding how to set and get static values from the parent class to the child class. My first attempt I had data in the parent class and the child class. I used DD accessors in all the classes (parent and child). It seemed to work but there was zero code reuse.

 

My second attempt I had data in both parent and child and only static accessors in the parent class. This attempt although it had reuse didn't work because my child classes didn't have access to the parent class data.

 

This attempt I have static accessors in the parent class and data in both parent and child classes. I used DD Vi methods in the parent and children classes. In the DD Vi Methods I made use of the "Call Parent Method" and it gained me access to the data. So now I had what I considered a nice OOP methodology of code reuse: Static Parent Accessors and unique DD Vi Methods.

 

Thanks again for all your help. You helped the light buld go off in my head.

 

0 Kudos
Message 9 of 12
(5,507 Views)

I dont exactly follow what you're saying in this last post, because i think you're confused. tst was on the same thought process as me when he said "Generally, you shouldn't have an enum for deciding what to do - that's exactly the point of having the hierarchy"

 

The main idea that I think you're missing is that if you create an accessor in the parent class, you can call that on the wire of a child. Remember the Child IS-A parent, that means that anything you can do to the parent, you can do to the child.

 

So in your example

on a CertDev wire, you can call the Write Rate.vi. There is no call to parent, not extra vi's created in the child class, no enums, nothing special.

0 Kudos
Message 10 of 12
(5,496 Views)