LabVIEW
LVOOP
This got lengthy... Hope you can follow.
@SimonAldred wrote:
How does a child class access a parent method?
It doesn't, you call a parent method. If it's the same method, sometimes you need the Call Parent Method node. Data from an object can't (shouldn't) be accessible from ancestors, siblings or descendants. That is by design.
If the method just adds two numbers, it could simply have two numbers as input. You can then use the method as a sub VI from any other VI, including child class methods. Assuming the add vi is public of course. Inheritance would allow specific add methods, but the data inputs are fixed.
@SimonAldred wrote:
When I write data to the child object and pass this to the parent function the parent doesn't see the child data. It only sees its own data, which doesn't exist.
The child writes to the child object's data, and that is (and should be) private to the child. Same goes for the parent. As you've noticed and mentioned.
If you want the parent to add two of it's private data members, you need to give the parent one or two methods to set those private data members (e.g. "Set Values To Add.vi"). That method should probably be protected, so only children can set them. Only the parent has values to add in it's private data.
Alternatively, you can give the parent a method "Get Values To Add.vi". The children can overwrite that method. When the add method is called, the "Get Values To Add.vi" of the object is called. This can be the parent, or any of the siblings.
In this example the second way seems weird. But that's only because the example is specific. In the example, each child would have private data members to store the values. But in practice, those values could be anything, including DAQ, file access, etc.. Then it makes more sense.
Note that Get and Set methods are frowned upon in other languages. That is because children in e.g. C++ do have easier access to parent data (IIRC). Get\Set then implies the implementation is exposed to the world. That is still true in LabVIEW. They are sometimes needed though, as children and parents simply have overlapping implementations. So those Get\Set methods would (preferably) be protected, so only the details are only exposed to the hierarchy.
Of course, sometimes it makes sense to have public Get\Set methods. For instance, when you initialize an object by giving it a reference, that's a set that can't be avoided. Or a file access class might have a "get results" method.
Rule of thumb is: what happens when I completely change my implementation? Will the interface (the API part of the contract with the class) still hold? If not, exposing the data is probably bad. You should be able to completely change the implementation of the class, without effecting any of it's users. In a perfect world of course, but also in practice this is one of the great things about OO.
Hang in there. You're facing the overwhelming number of possibilities that OO has to offer. It seems like a jungle at first, but once you get comfortable, you'll gain so much power you never want to go back.
Hope it helps...
Search LabVIEW like a graph! 