Classes with references to controls in their private data.

[Arthur P]

Is it a bad idea to have a class keep a couple references to some controls on my main GUI's front panel?

Right now, whenever there is a change in the class's data, I call one of the class's member VIs to manipulate the data, then to populate the main GUI's display I have to call a few more of the class's member VIs and pass in references to the controls that need to be updated. I think that it would be simpler to just pass in the control references to the class as soon as it is initialized, and then have the class update the controls internally whenever the class's data is updated. However, this could be a style issue because the controls are being modified without a direct call from the VI that owns them.

If I've completely missed something and there's a better way to handle this situation, I would love to hear it!

[Ben]

Fully analyzing your design is beyond what we can handle here but I share my thoughts in the hopes others will chime in with their thoughts.

Most of the OOP theory focuses on stuff that is below the GUI and the GUI itslef is for the most part ignored in the theory I have read.

In my experience I have found that the GUI's are generally tightly coupled to the application requirements and it would require a fine razor to sepearte the two. With this in mind I develop my LVOOP apps such that I have a my standrad library of classes that can be used in multiple applications AND an app specific set of classes that are used by the GUI to interact with the standard classes.

So what I end up with is my standard classes plus a set of app specific classes.

Now to your question.

Provided the control refs are used only by the GUI objects, I see no design flaws in that approach.

A step farther...

I have developed as set of 3D classes that let me realize a variety of 3D renderings. At the heart of that set of classes is a reference to the 3D picture the calsses work with. Again the objects are tightly coupled because they have to be coupled (a 3D class that has no display would be a OOPish version of "If a tree falls in the woods...").

SO that is my two cents.

Let er fly if if you think I should concider other options.

Trying to help,

Ben

[yenknip]

It's not a bad design, but personally, I would go the other way; provide a means for a lower level class to indirectly manipulate a higher level. That way, there is one defined method for multiple locations to control the GUI, and that method is held within the GUI library.

The way I thnk of it, the reference is owned by the GUI, so the GUI should be sharing the reference rather than delegating it elsewhere; it could be in an Action Engine or notifier so that if need be, one update will propagate to everywhere the change is needed. If a number of classes have the reference in their private data, then a 'refresh' call will need to be performed on each class.

I totally agree with Ben; the GUI is very specific to an application - but there is always room for scope creep and change. So when designing abstraction and classes, I prefer as few inter-connected dependencies as possible.

There was a great nugget recently where the GUI had a space defined for a class to display its own data. The class is able to define how it wants the data to be displayed with zero change or communication to the top level GUI.