値管理クラスが必要

例えば、座標を持つクラスがあったとする。
当然そのクラスは「Point」というプロパティを持つ。
しかし、その値を直接値で盛ってしまうとなにかと不便だ。問題回避を逃がすコードでプログラムが無茶苦茶になったことがある（何度も）。
その必要性を解説する。

プロパティで直接値を持つと不便な理由

その１：複数選択時

複数選択時に値を変更すると、複数のアイテムに「相対指定」で値を加算していくことになる。
例えばアイテムAの値が、アイテムBの値が15としよう。
Aの値が22になったらBは12を足して27になる。
その際、プロパティでやりとりすると、
①Aでプロパティからイベント発行し、
②選択ロジックに通知
③選択ロジックが選択物全体へ差分12を足す。
という流れになるが、Aは自分が既に計算済みであるというフラグを持たなくてはいけない。そのフラグを見に行くのもめんどくさいしそのフラグを下げるタイミングも非常に難しい。絶対バグる。

その2：何かを参照する

アイテムAがアイテムBの座標を参照している場合、またはアニメーションカーブを参照している場合、プロパティで直接管理していると、「プロパティに値を与えるロジック」が必要になる。
当然何かを参照しているというフラグも必要になり、その何かを記録する変数も必要になり…と、アイテムＡの値周辺は鬼コードになる。必ずだ。

値管理クラスで解決

以上の問題点を解決するため、最初からプロパティは「窓口」に専念させて中身は「値を発行する頭のいいクラス」に任せる方がいい。
・複数選択時の計算方法（delegate)
・自分が発行者の場合のロジック
・参照方法（interface)
　参照方法は多岐に渡るので各命令ごとにクラスを持ちたい

また、
選択ロジックが「プロパティ名」を文字列で拾えるよう、そこの情報も保持する必要がある。

アウト（get）はいいとしてイン(set)はどうするか

直接メソッドを叩く方が安全だが、一旦プロパティを経由しなくてはならない。なぜならバインドするから。

その他

参照の場合、参照先からのイベント発行で参照する方を駆動した方が美しいと思うが、イベントの削除やら無限化バグが怖い。親ロジックを叩く方で頑張ろう。