Access private data without accessor method possible?

[dlanger]

Is there any way to access an element of the private data of an LVOOP class from outside the class without having an accessor method?

Specifically, I would like to check whether some element is present in the private data of a child class from within a dynamic dispatch method of the parent class. Further, if the element is present, I would like to have read/write access.

Is this somehow possible, no matter how dirty the hack?

[Ben]

---

@dlanger wrote:

Is there any way to access an element of the private data of an LVOOP class from outside the class without having an accessor method?

Specifically, I would like to check whether some element is present in the private data of a child class from within a dynamic dispatch method of the parent class. Further, if the element is present, I would like to have read/write access.

Is this somehow possible, no matter how dirty the hack?

---

No.

A lot of LVOOP would blow-up if you could.

Please tell us more about what you are attempting, ther may be another way.

shooting in the dark example.

You could test if the class is a child of a class that has those values and cast the wire as the appropriate type and then invoke the appropriate accessors.

Ben

[hecmar.arreola]

I'm having a hard time understanding why an Accessor is undesirable in your situation... could you please elaborate on why you think a hack would be more perferable than an accessor?

NI locked down LVOOP in order to mandate good OOP practices and prevent sloppy programming.  And although it can seem like they are holding you back with this mandate, IMO they are lifting you up.

[Ben]

---

@Nickerbocker wrote:

I'm having a hard time understanding why an Accessor is undesirable in your situation... could you please elaborate on why you think a hack would be more perferable than an accessor?

NI locked down LVOOP in order to mandate good OOP practices and prevent sloppy programming.  And although it can seem like they are holding you back with this mandate, IMO they are lifting you up.

---

Agreed!

Over-rides are implemented at the VI level. By using Accessors we get fine grained abilities to over-ride on a property level. So accessors do enable us.

Ben

[hecmar.arreola]

Also, if you ever decide to change the data structure of the private data of a class, you can re-work the accessor to be compatible with the new data structure and keep your code working.  If your code refers directly to the private data in various points, you could be up against a LOT of recoding.

Example:

Say you have a class that represents a person.  Initially you decide to store the age of a person as an integer.  You create an accessor "Read age.vi" that returns the age from the private data within the class.  A year later (when you are going through all your records updating the age of each person and cursing at yourself), you decide it would make much more sense to store the Date of Birth (duh, why didn't I think of that the first time through).  Don't fret, because you were following good OOP practices and made an Accessor for the Age and not accessing the private data directly in all your code.  Rewrite the "Read age.vi" so that it calculates the age based on the data stored in the Date of Birth field and the current date and bam, you are done.  No need to go back through and find all the places you accessed the private data directly.

Re-writing your "Write age.vi" can be a little more tricky... but you can write it in such a way that the integer Age input to the VI is handled in a graceful way.

This is a very powerful feature of OOP.

One step further, is to ONLY use the accessors to read/write private data.  I use the accessors even within my class VIs because it is so powerful (even though the private data can be accessed directly).

[dlanger]

Thank you for your feedback, Nickerbocker and Ben. Let me briefly explain my reasoning...

I have a hierarchy of classes ("components"). Each component is a direct or indirect child class of GenericComponent.lvclass. GenericComponent provides the methods initialise.vi and terminate.vi. A component class can have "sub-components" as part of its private data. In such cases, it has to override the initialise and the terminate methods in order to call the initialise (or terminate) method for each sub-component.

Now I thought that instead of a developer having to override the initialise and terminate method for his component class if it contains sub-components, there could just be the convention that he had to put all the subcomponents into a cluster named "sub-components". If the initialise and the terminate method of the GenericComponent had somehow access to the private data of child classes, they could just walk down the class hierarchy and inspect the child classes' private data, looking for a cluster named "sub-components". If found, they could loop over the cluster elements and, based on the implicit convention that this cluster contains only classes derived from GenericComponent, call the initialise or terminate method of these elements.

Maybe it's indeed cleaner if I just instead had the convention that a developer has to override two methods get_subcomponents.vi and set_subcomponents.vi for his component if it has sub-components. GenericCompenent:initialise.vi and GenericCompenent:terminate.vi would then use these accessors instead of a dirty hack to get access to the sub-components.

Of course, overriding get_subcomponents.vi and set_subcomponents.vi is still more work for a developer than just following a naming convention for a cluster - but I am not starting to shoot holes into the data encapsulation commandment.

I would be happy for any further feedback.