LabVIEW
Silly & basic question - where did my child data go?
I don't understand what you mean with 'rolled into', i do hope that doesn't mean you're trying to access child data from the parent somehow.
A class always works with it's own and it's parents data, a parent never uses/handles a childs personal belongings (data, think you wouldn't want your parents to handle your bank account and surf history, would you?).
Maybe it's easier to think of it in an evolutionary sense, a parent is 'mammal' and children 'cats', 'dogs' and 'cows'. To have the code general we place and use the Mammal-methods everywhere, but the implementation is up to the individual childclass. The method 'create mammal glands' will look quite different between cats and cows, for instance.
@tyk007 wrote:
Accessor VIs are just VIs. They can do anything you want as long as you have the class on the connector pane. Yes the IDE can auto-generate some for you that access class private data but that's just a convenient shortcut. So your parent class could have a DD VI that returns the same data type as your child classes (its default logic could be to return the default value for that data type).
Actually in this specific case you probably should mark the accessor VI in the parent (abstract) class as "must overwrite". As it doesn't do anything useful for a parent class instantiation (it's an abstract method just there to define the access interface for the object hierarchy) it should really force any inheriting class to implement an overwrite method.
@Yamaeda wrote:
I don't understand what you mean with 'rolled into', i do hope that doesn't mean you're trying to access child data from the parent somehow.
A class always works with it's own and it's parents data, a parent never uses/handles a childs personal belongings (data, think you wouldn't want your parents to handle your bank account and surf history, would you?).
I think you took the generational analogy a little to far here. In the case of bank accounts and surf history the desire to not access each others data usually goes in both directions. 😀
A parent has indeed no business accessing a childs data directly. If you ever feel the need to do that in an implementation, step back, take a deep breath and throw everything away and start from scratch again! 😁
But a parent can be (exclusively or partially) an interface definition and in doing so, absolutely can define an interface that a child should/must implement, to access something that the parent basically implies a child should have. Otherwise that child should not need to inherit from that (interface) class.
The complication in the OPs problem is that he wants to have analog and digital children. So if the parent (interface) defines a Get Data.vi accessor method it needs to be implemented in a way that it can return both types of data. Or you implement a Get Analog Data.vi and Get Digital Data.vi method in the parent and overwrite the according method in the child, but that is not very scalable if you ever intend to extend the hierarchy to support other data types and should be avoided whenever possible. It also burdens the user of Analog child to worry about the Get Digital Data.vi method which has no functionality. That is really muddying the object interface definition and generally an ugly solution, but often chosen as quick and dirty implementation when extending existing class hierarchies, as a proper redesign would require changing the parent and all its already existing offspring. 😂
You can give the analog child a Get Data.vi that returns double(s), and give the digital class a Get Data.vi that returns Boolean(s).
If the parent doesn't have a Get Data.vi method, the connector panes don't have to match. The returned data can be a double(s) and Boolean(s) indicator. But you won't have run time polymorphism. You will get compile time polymorphism, for instance if you use Get Data.vi in a .vim. So you can get doubles from a analog class, but you can't call Get Data.vi on an array of analog and Boolean objects. Well, you can, but you have to cast each individual object to it's more specific class. This is a code smell, not something you want...
Another option is to make the returned data the same type. Variants, flattened data, strings, or a data class will do the trick. The parent can now define the interface, as all 3 connector panes can be the same. This will allow run time polymorphism. But it just 'delays' the problem. You get the exact same issue with the data class, but later on. Still useful, if the data class has (or supports) functions to visualize, write to file, store to DB, etc. These functions are better of delegated to the data class, or even better: interfaces using it.
Of course you can give the parent Get Data.vi both double and Boolean outputs. Then make the analog class use the doubles output, and the Boolean class the Booleans output. Another code smell, this will soon confuse everyone, including yourself.
This problem is typical when you're using inheritance to extend a parent. Polymorphism is easier to comprehend (and like) when children implement their parent. Your example does both: it implements it's parent (e.g. acquire.vi) and extends it (e.g. get child specific data.vi). This is useful, but not a typical use case for polymorphism. You still get to enjoy encapsulation, inheritance and compile time polymorphism.
This might not be a problem you want to use to learn (or like) OO. It will give the impression that OO is really hard. But in fact, the problem is hard. For instance, think about solving the exact same problem without OO... My guess is it will be equally hard or even harder.
Search LabVIEW like a graph! 
