Why would a OOP developer seperate the data used in a class from the class itself?

[Ben]

A LVOOP project ended up on my desk and I am mystified why the previous developer worked so hard to ensure there was NO private data in any of the classes that where used for each test mode.

I would love to share so that maybe somebody else could figure it out, but alas, no sharing allowed.

He has a Parent Class from which children inherit basic methods like sizing and positioning the screen. That part makes sense.

Each of these children are associated with a test mode. There is an over-ride VI for the GUI that is presented for each test mode. Again this makes sense so he can just use a factory pattern and invoke the right type of test mode operation.

But...

While the GUI (the over-ride I mentioned) has a state diagram to realize each type of test, the parameters, options settings used by that class are not in the private data of the  class!

While I have figured out that he has created a "Data" class that is associated with the that top Parent class I mentioned above. For each of the over-ride classes there is a child of the DATA class that is associated with each of those Classes used to run the particular test.

It has me curious why one would not want any private data in the Class data that is used for each mode of operation.

I can not contact the original developer to ask myself. But he was a wiz-bang IS type with an advanced degree so there may be some computer science theory that he was trying to realize in LV.

So far it just strikes me as being a pain in the arse since the data I need is not in the class I am working with.

Please feel to edify this old man if you have any clue based on my lame description.

Ben

[crossrulz]

I have one set of drivers that use two classes to operate: one for the interface and another for the state of the driver.  That is the only thing I can possibly think of.  Perhaps you can make a reduced example just so we can see how the code is actually used.  The structure is the only thing I am remotely interested in, so simple screen shots would do the trick.

[wiebe@CARYA]

It only makes sense if the objects can dynamically change. Then it is very practical to pass the object data from one object to the other. More or less a state pattern. Each state is a child class, and the state object can decide what the next state will be. But when the state changes, it's convenient to pass an object, iso individual items. Doesn't seem to be your situation, but maybe this was his old (or new) idea. But if all the child modes have exactly the same data, it could still make a bit of sense if this data is reusable on it's own.

[Kyle97330]

Well, I'm not 100% sure I am understanding what you're describing correctly, but maybe the developer was coming from a reference-based language and was using this to compensate?

In something like C#, you can copy a pointer to an object and two different functions can manipulate the same object in parallel.  But as soon as you fork a wire in LabVIEW you've just created two copies in memory, and a strange trick where you didn't put any data inside the object is a way you could work around that.

[Yamaeda]

Since LV object pass data by value separating the data could be useful to throw less data around, it also reminds of modern .net where you have some 3 layer system.

/Y

[Ben]

Thanks to all for trying!

The parent class from which all of the others inherit is set-up to be a type of universal state machine. The children are all variations of such. There is some interaction between multiples of these instances such as one exposing configuration options for the others so there are DVRs used to allow one to configure the others.

Compared with non-LVOOP coding is seems very convoluted and the formality of the architecture makes it seem cumbersome to get at what would seem straight forward using a traditional LV approach. But the data sharing and multiple layers of abstraction are probably what the original develop was trying to achieve.

Thank you for the insights and inspiration!

Ben

[Intaris]

I've been pondering this thread for a few days as it kind of reminded my of something, but I couldn't remember what.

I think I've done this in the past.  I did it essentially out of neccessity to have a self-defined state object being handed off to different manipulators.  While a cluster might have also done the same thing, essentially a "model" is created with encapsulation and accessors and methods.  By passing this "model" which ensures data consistency to different "handlers" or "manipulators" I could modify behaviour separately from the data underlying it.  I might have been able to get a similar result by decorating the Models but I found the inherent decoupling offered by retaining my "model" as a class to be soothing.

This way I can extend and modify my models and my handlers independently of each other.  Trying to do this within a single hierarchy tree will quickly make you seek a different career.