LVOOP: Common accessor for child classes?

[dthor]

I'm reletively new to LVOOP, and OOP in general. I've used very simple classes as a replacement for clusters a few times, and now I have an architecture planned out to convert more of my code to classes, dynamic dispatch VIs, and the like.

However, I'm running in to one issue, which in essence boils down to lazyness: I don't really want to make a bunch of the same dynamic dispatch VIs. I want to have a parent VI be able to write a piece of data that is common to all children. Preferrably gives an error if the child does not have that data element.

I guess it's pretty similar to dynamic dispatching, but without having to write a DD VI for each class.

Is it possible to have the parent VI access the child's data? If so, how?

Here's an example of my heirarchy:

Test.lvclass (parent)

   DC_test.lvlcass (Data: test number, 2D results, timestamp)

   Transfer_Curve_test.lvlcass (Data: test parameters, 1D results, timestamp)

   Breakdown_test.lvlcass (Data: test number, 3D results, timestamp)

   ... 28 other test

As you can see, the only common datatype between them is the timestamp. I want to be able to use a VI in the parent class to write data to the child class.

[Intaris · Accepted solution]

You have it the wrong way around.

The data which is common belongs in the parent class, not the child class.

Data which is not common cannot be dealt with by the parent class and must be processed by the child class.

You don't need to actually CREATE dynamic dispatch VIs for a common datatype.  If you just don't define the VI at all, the parent instance will be called.

Shane.

[Ben]

parents have no knowlege of their children so no-go.

YOu could implement a "place keeper" method in the Parent that returns an error for the parent class but can be overridn by the child classes where they are supported but that is concidered "BAD LVOOP".

Another approach would require you re-think your classes and methods so that you can have a "Do Something" method that can be overriden in the child. the "Do Something" method would know about the data is has to ""Do something" to and knows not to use 3D data for a scalar.

Ben

[dthor]

Hmm... Ok yes, I understand that, but won't that give the same timestamp value to each child? The data type is the same, but the data itself is different:

Test.lvclass (parent)

   DC_test.lvlcass (Data: test number, 2D results, 08:21:33 10/31/2011)

   Transfer_Curve_test.lvlcass (Data: test parameters, 1D results, 22:18:12 09/30/2011)

   Breakdown_test.lvlcass (Data: test number, 3D results, 02:02:02 02/02/1922)

I end up calling the child class later to analyze the data or or write it to a file, and I need individual timestamps for each test.

[Ben]

---

@Intaris wrote:

You have it the wrong way around.

The data which is common belongs in the parent class, not the child class.

Data which is not common cannot be dealt with by the parent class and must be processed by the child class.

You don't need to actually CREATE dynamic dispatch VIs for a common datatype.  If you just don't define the VI at all, the parent instance will be called.

Shane.

---

That is the approach I take! The only time I duplicate the whole thing is when I plan to expose a class for public use, just to avoid the example code looking like a rainbow.

Ben

[Ben]

---

@dthor wrote:

Hmm... Ok yes, I understand that, but won't that give the same timestamp value to each child? The data type is the same, but the data itself is different:

Test.lvclass (parent)

   DC_test.lvlcass (Data: test number, 2D results, 08:21:33 10/31/2011)

   Transfer_Curve_test.lvlcass (Data: test parameters, 1D results, 22:18:12 09/30/2011)

   Breakdown_test.lvlcass (Data: test number, 3D results, 02:02:02 02/02/1922)

I end up calling the child class later to analyze the data or or write it to a file, and I need individual timestamps for each test.

---

The parent of those classes can have the time stamp. Ecah child can have over-rides if required get at its own verson of the time if it different than the parent.

Ben

[Intaris]

No it won't result in each child getting the same value.

There is a difference between functional inheritance and data inheritance.  Although an inheritance tree for class functionality may resembe a family tree with common ancestors and what not, each actual object as it exists on the block diagram has its OWN family tree.  There is no overlap in data space.  You just need to try it to realise how it works.  Each child object is actually a chain of objects from child back to root.  This chain is replicated for each and every instance of the object you might create, each with their own complete data space.

Shane

[dthor]

---

@Intaris wrote:

No it won't result in each child getting the same value.

There is a difference between functional inheritance and data inheritance.  Although an inheritance tree for class functionality may resembe a family tree with common ancestors and what not, each actual object as it exists on the block diagram has its OWN family tree.  There is no overlap in data space.  You just need to try it to realise how it works.  Each child object is actually a chain of objects from child back to root.  This chain is replicated for each and every instance of the object you might create, each with their own complete data space.

Shane

---

Ah, alrighty then! This is great guys, thanks a bunch. I guess I had a fundamental misunderstanding of OOP. Good thing I'm not a real programmer, just a physicist 

I put all the common data into the parent class, and it looks like this will work wonderfully for what I need to do. Thanks guys! Now to figure out who gets the solution...

[Ben]

---

@dthor wrote:

---

@Intaris wrote:

No it won't result in each child getting the same value.

There is a difference between functional inheritance and data inheritance.  Although an inheritance tree for class functionality may resembe a family tree with common ancestors and what not, each actual object as it exists on the block diagram has its OWN family tree.  There is no overlap in data space.  You just need to try it to realise how it works.  Each child object is actually a chain of objects from child back to root.  This chain is replicated for each and every instance of the object you might create, each with their own complete data space.

Shane

---

Ah, alrighty then! This is great guys, thanks a bunch. I guess I had a fundamental misunderstanding of OOP. Good thing I'm not a real programmer, just a physicist 

I put all the common data into the parent class, and it looks like this will work wonderfully for what I need to do. Thanks guys! Now to figure out who gets the solution...

---

Ditto that!

Ben

[Intaris]

---

dthor wrote

:Ah, alrighty then! This is great guys, thanks a bunch. I guess I had a fundamental misunderstanding of OOP. Good thing I'm not a real programmer, just a physicist 

I put all the common data into the parent class, and it looks like this will work wonderfully for what I need to do. Thanks guys! Now to figure out who gets the solution...

---

I'm not a "programmer" either and OOP had me baffled for YEARS before LVOOP came along and I realised that inheritance was a compile time thing, not run time action.  I never programmed OOP before LVOOP because I could not get my head around a run-time inheritance change and how in heck that is supposed to work.  If I don't understand something properly, I don't feel comfortable using it in the real world.

I've re-checked my programming books and have not found any explicit statement that inheritance is a compile-time thing.  Guess everyone else just understood that whereas stupid me kept asking questions*.

Shane.

Spoiler

I was told once regarding asking "stupid questions".  If you ask a "stupid" question you might look stupid for a moment but if you don't ask you're stupid for the rest of your life.