How to make a child class extend a parent class?

[DavidEntenberg]

Hi everyone,

  I'm getting deeper into object oriented programming with labview. I've got parent and child classes working well, and have done overrides and polymorphism. What escapes me is how to make a child class extend a parent. For example, I have a parent class, Detector. It defines a number of properties and methods and serves as a simulated device. I have a child class, Hardware Detector, which basically is a copy of all of the above, but with a different, overriding implementation that calls some actual hardware to do the detection. The big difference between the two is that the child should have an extra property, Hardware Address, which the parent doesn't have or need. However, when that is included in the child, then I'm unable to have something like an initializer which overrides the parent as there are different inputs. For this reason, I've had to make my child class have many of the properties that also exist in the parent. I thought that the common properties would be defined only in the parent, and the unique items only defined in the child. It seems like I'm not using the parent and child properly.

Can someone provide an example of how this might work?

Thanks,

Dave

[ZYOng]

You can instantiate an instance of a child object with the child-only properties and use an accessor VI to access the parent data. 

How Do I Access Private Parent Class Data Members in LabVIEW OOP?

[wiebe@CARYA]

You have a few options.

1) Instantiate the child, so you have all it's methods (like a specialized init)

2) Cast to the child when needed, call the extension methods.

3) Make a generalized init, for instance by passing some config object, (file) reference, even a string or variant.

4) Make a parent method that supports all inputs, and make only some childs use it.

1) Works great if you use the classes statically (e.g. hard coded, knowing at edit time what object you want). Simplest solution if you can get away with it.

2) Is somewhat of a hack. For instance, you should be able to add a child, without having to modify the callers. Which is not what this method does.

3) Is usually more work, but scales up well.

4) Is just an ugly hack, parent should be bothered by child implementation details. It does the trick, but doesn't scale up.

[rolfk]

---

wiebe@CARYA wrote:

4) Is just an ugly hack, parent shouldn't be bothered by child implementation details. It does the trick, but doesn't scale up.

---

You missed an important negation there. 😁

[wiebe@CARYA]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

4) Is just an ugly hack, parent shouldn't be bothered by child implementation details. It does the trick, but doesn't scale up.

---

You missed an important negation there. 😁

---

Yes, that's a big mistake.

[DavidEntenberg]

Thanks for the reply!  

I had started going down the route 4 you listed (make the parent have the same properties as the child), but I really wasn't happy with this. With multiple child classes, the parent would get polluted with unnecessary properties. Instead, I'm thinking of using a solution somewhere between somewhere between option 1 and 2 you listed.

I created a parent with its own properties, and a child which extends the parent. The child has one additional property (the hardware address). I then create a constructor vi for the child which has inputs for all of the properties of the child and parent. In this constructor I use the "To more general class" function on the child object to wire it to the parent's constructor. The inputs specific to the parent are passed to this constructor. I then use "to more specific class" to downcast the child object before having it exit from the child's constructor.

The only trick in this is that the child's constructor can't be named the same as the parent's constructor or Labview will try to make the constructor an override and complain that they have different inputs.  I've attached a screenshot of the two constructors and the test VI. 

Let me know what you think of this. Will it work well? Am I likely to run into problems later on?

Thanks!

Dave

[wiebe@CARYA]

---

@DavidEntenberg wrote:

Let me know what you think of this. Will it work well? Am I likely to run into problems later on?

Dave

---

That will do nicely.

The cast to parent is redundant, the method is static, and the child is a parent. So the cast will happen automatically. There's a change that that eliminates the need for the to more specific too, as LV can often figure the class (if the VI's input\output is 'feed though'). If LV doesn't automatically detect this, I'd use Preserve Run-Time Class.

[DavidEntenberg]

That's great. Thanks so much!