我的问题涉及属性之间的关系和级联效应，我想知道最佳做法是什么。
我有一个包含不同长度数字列表的类。编辑列表时，有时用户更喜欢设置TargetSum，以便程序强制执行列表将始终添加到此总和。我通过以编程方式设置列表中的最后一个元素来实现这一点，即list sum = TargetSum。例如，如果用户选择UseTargetSum，则设置TargetSum = 10，然后创建长度为4的列表，并为前3个元素输入1,4,2，然后将最终元素以编程方式固定为3.用户不能改变最终元素本身。
我通过处理所有必要的事件（例如列表元素值更改，列表长度更改和UseTargetSum选项更改）在幕后执行此操作。对于每个事件触发器，它会重新计算最后一个元素的值。
它可以工作但是在加载保存的数据时出现了错误。如果通过顺序添加元素来加载列表，则处理程序会修改每个条目。关于该示例，当输入第一个值1时，处理程序说“刚刚添加了一个值，总和应该是10，当前只有一个元素，所以它需要是10”。所以第一个元素在幕后变为10。当下一次添加第二个元素时，处理程序说“刚刚添加了4的值，但第一个元素已经是10，所以它应该为零。”在加载结束时，最终列表为10,0， 0,0而不是1,4,2,3。
我知道可以重新安排加载程序，以便获得正确的列表。例如，我可以避免在加载所有数据之前启用TargetSum事件处理程序。该列表将首先创建为1,4,2,3然后处理程序将不会更改任何内容。
但是这种经历让我想知道我是否打开其他偷偷摸摸的副作用的大门。看起来你应该能够加载数据而不必过多担心隐式排序。在类属性之间具有“级联”效果似乎也很不寻常。是否有更公认的方法？
我正在考虑的另一个选择是仅在UI表单中强制执行TargetSum。即，当您知道是用户进行更改时，请执行TargetSum，否则只留下核心类逻辑。这样，数据库加载等不受影响。但我认为没有无处不在的强制执行的缺点是，通过一些无法预料的并发症打开了错误总和的大门。
答案 0 :(得分：0)
首先，我会在类中使TargetSum成为整数属性。接下来，您需要扩展管理列表的任何功能，以便在对列表中的值进行任何操作之前加载所有值。