プロパティ間の内部的な関係

Question

私の問題は、プロパティ間のリレーションシップとカスケードエフェクトが関係しており、これに関するベストプラクティスが何であるか不思議です。

私は、さまざまな長さのリストを含むクラスを持っています。リストを編集するとき、ユーザはTargetSumを設定することを好みます。そのため、プログラムはリストが常にこの合計に加算されるようにします。私はこれを、list sum = TargetSumのようなリストの最後の要素をプログラムで設定することでこれを達成しています。たとえば、ユーザーがUseTargetSumを選択した場合、TargetSum = 10を設定してから長さ4のリストを作成し、最初の3つの要素に対して1、4,2を入力すると、最後の要素はプログラムで3に固定されます。最終要素自体を変更してください。

これは、リストエレメントの値の変更、リストの長さの変更、UseTargetSumオプションの変更など、必要なすべてのイベントを処理することによって、バックグラウンドで実行されます。イベントトリガごとに、最後の要素の値が再計算されます。

動作していますが、保存したデータを読み込むときにバグがありました。要素を順番に追加してリストをロードすると、ハンドラは各エントリを変更します。この例では、最初の値1が入力されたとき、ハンドラは「値が追加されたばかりで、合計は10でなければならず、現在要素が1つしかないので、10でなければならない」と述べています。したがって、最初の要素はシーンの背後で10に変更されます。 2番目の要素が次に追加されたとき、ハンドラは「4の値が追加されたばかりですが、最初の要素はすでに10であるため、ゼロでなければなりません」と言います。ロードの最後に、 1,4,2,3の代わりに0,0。

私は正しいリストを得るようにロード手順を再編成することが可能であることを知っています。たとえば、すべてのデータがロードされるまでTargetSumイベントハンドラを有効にすることを避けることができます。リストは最初に1,4,2,3として作成され、ハンドラは何も変更しません。

しかし、この経験は、私が他の卑劣な副作用のためにドアを開けているのだろうかと思います。あなたは暗黙の順序についてあまり心配することなくデータを読み込むことができるはずです。クラスプロパティ間に「カスケード」効果があることも珍しいようです。より受け入れられたアプローチがありますか？

私が検討しているもう1つの選択肢は、UIフォーム内でのみTargetSumを適用することです。つまり、変更を行うユーザーであることが分かっている場合は、TargetSumを適用します。それ以外の場合は、コアクラスのロジックをそのままにします。そうすれば、データベースの負荷などは影響を受けません。しかし、私は、ユビキタスな執行力を持たないという欠点は、予期せぬ複雑な合併症によって不正確な金額の扉を開くことだと思います。

Answer 1

まず、TargetSumをクラスのIntegerプロパティにします。次に、リスト内の値を操作する前に、すべての値がロードされるようにリストを管理する機能を拡張する必要があります。