Collection of child objects needing access to same parent data?

[ned]

I'm working on an application to test a device. There are at the the moment three modes: 1) run the device; 2) run the device and take measurements; 3) run the device, adjust a parameter through a range of values, and take a measurement at each point. This seemed like an ideal case for LVOOP, so I set up a parent class for "Run," a child class for "Measure," and a child of that for "Sweep." The sweep class has common logic for incrementing a value through a range, and has a child class for each parameter that contains the logic for setting that specific value. This all works great and I'm loving LVOOP.

Now the engineer using the tool wants to sweep more than one parameter at a time, taking a measurement at every possible combination, and I'm trying to figure out a way to do this with minimal changes. My "Run" and "Measure" objects store most of the parameters. I started creating a new child of "Sweep" called "Sweep Collection" that contains an array of Sweep objects, but then I realized that each individual Sweep object would contain its own copy of all the data stored in the parent Run and Measure objects, which won't work - all the sweep objects need to share that same data because the parameters that are being changed are part of that data.

One solution is to put the common data into a singleton class or functional global. Anyone have other suggestions?

[ned]

Just after posting this I started a different approach: I moved the "Sweep" logic out of the Measure hierarchy and added a "Measure" class input and output to each of the Sweep functions. I'll leave the Sweep Collection object as a child of Measure, and it will still contain an array of Sweep objects. When I need to set a parameter through the one of the Sweep objects, I'll pass in the Sweep Collection object. I think this will be cleaner. Still curious to hear how others have approached a similar situation.

[asbo]

Conceptually, I don't think the Sweep Collection belongs in the Measure hierarchy. The Sweep Collection itself does not need any of the functionality provided by parent or child; it accepts an array of Sweep objects that it can operate on. Only /those/ objects care about the Run/Measure functionality and need to be in that hierarchy.

In this same vein of thinking, I would likely have also pulled the Sweep logic out of the Measure hierarchy. I might even go as far as requiring every Sweep to be handled through a Sweep Collection, not to be dealt with directly.

[ned]

Back on this topic again, a few months later. I have a design that I like, but one part of it (shown below) looks a bit ugly to me, and I'm wondering if others would take the same approach or would arrange the data differently.

My system dispenses droplets of liquid and measures them. There are a number of parameters that affect the droplet volume and velocity. The user can configure the system to vary any number of those parameters across a range, and the system tests every combination.

At the top level I have Dispense class that starts the system dispensing liquid with a fixed set of parameters. Then I have a Measure class which inherits from it. Measure contains an array of Sweeps, one for each parameter that the user wants to vary.

My issue is that each element of the Sweep array modifies a parameter that is part of the Dispense class. As you can see in the image, what I'm currently doing is pulling the individual Sweep out of the Measure class, feeding the Measure class to a Sweep method that updates the appropriate parameter, taking the updated Measure class value (which has now become the parent Dispense type due to inheritance rules) and forcing it back to a Measure class, then putting the updated Sweep back into the Measure object. Is there some better way to give an individual Sweep inside the Measure object access to the Measure object's parent data?

The code that's shown iterates through each Sweep until it reaches a Sweep that hasn't finished yet. The "Done?" method increments the appropriate parameter, and returns True when that parameter reaches the end of the range, which then causes that Sweep to reset to the beginning. This allows the code to test every parameter combination within the user-determined ranges.