internal relationship between properties

Question

My issue involves relationships and cascaded effects between properties, and I'm wondering what best practices are on this.

I have a class that contains a list of varying length of numbers. When editing the list, sometimes the user prefer to set a TargetSum, so that the program enforces the list will always add to this sum. I am accomplishing this by programmatically setting the final element in the list such that list sum = TargetSum. For example, if the user chooses to UseTargetSum, then sets TargetSum = 10, then creates a list of length 4, and enters 1, 4, 2 for the first 3 elements, then the final element is programmatically fixed to 3. The user cannot change the final element themselves.

I do this behind the scenes by handling all necessary events, such as a list element value change, list length change, and the UseTargetSum option change. For each event trigger, it recalculates the last element's value.

It works but then there was a bug when loading saved data. If a list is loaded by sequentially adding the elements, the handlers modify each entry. Regarding the example, when the first value of 1 is entered, the handlers say “a value was just added, the sum should be 10, there is currently only one element, so it needs to be 10”. So the first element gets changed to 10 behind the scenes. When the second element is next added, the handlers say “a value of 4 was just added, but the first element is already 10, so it should be zero.” At the end of the load, the final list reads 10,0,0,0 instead of 1,4,2,3.

I know it is possible to rearrange the load procedure such that I get the correct list. For instance, I could avoid enabling the TargetSum event handlers until after all the data is loaded. The list would first be created as 1,4,2,3 and then the handlers would change nothing.

But this experience makes me wonder if I am opening the door for other sneaky side effects. It seems you should be able to load data without worrying too much about an implicit ordering. It also seems unusual to have “cascading” effects between class properties. Is there a more accepted approach?

The other alternative I'm considering is to only enforce TargetSum only inside UI forms. Ie, when you know it's a user making the change, then enforce the TargetSum, but otherwise leave the core class logic alone. That way database loads, etc, are left unaffected. But I guess the downside of not having ubiquitous enforcement is that opens the door of incorrect sums via some unforeseen complication.

Answer 1

First, I would make TargetSum an Integer Property in the Class. Next, you'll need to expand the functionality of whatever manages the list so that all values are loaded before you do any manipulation of the values in that list.