相互依存

懸命に Toss のコード上での構造をどうしようか考えているところです。

C++ は、宣言と実装をヘッダ ファイルとソース ファイルに分離出来るわけで、
なかなかスッキリした形でコードを書いていけそうなわけで。
まあそれはいいとして、せっかくのオブジェクト指向、
分かりやすく活用出来ないか頭をひねります。

話のために、StatusFlag を例に取ります。

StatusFlag は、中枢の上にユーザー プロファイル管理部門が乗っかり、
更にその上にプラグイン管理部門、メイン ウィンドウ管理部門、
グラフ描画部門、ダイアログ管理部門などが乗っかっています。
それらは、ユーザー プロファイル管理部門へ自分のところの処理を頼んで読み書きしつつ、
他の部門と「互いに干渉しながら」動作している状況です。

プラグイン管理部門がプラグインごとの設定を読み込めば、
グラフ描画部門がグラフごとの設定を読み込みそれと「関連付け」、
メイン ウィンドウ管理部門が定期的にグラフ描画部門へ描画を頼み......。
ダイアログ管理部門は、オプションで [OK] ボタンが押されれば
メイン ウィンドウ管理部門やグラフ管理部門、プラグイン管理部門へ設定の再構築を頼み...。

他の部門に何か頼むときは部門が公開している窓口（メソッド）を使うなどしますが、
それがかなり相互依存を引き起こしているのです。

Toss も最初はこの切り口で作っていこうと考えていたものの、
なんかこの状況だと、全ての部門がグローバル変数的状況に置かれ、（でないと頼めない）
オブジェクト指向な振る舞いが、この構造を組み立てるための柱としての機能のみを
持つようになっており、思い返すと納得がいきません。

親の管理下に置かれている複数の子オブジェクトが互いを参照したいとき、
・親を通じて自分以外の子を認識する→相対的な経路
・まず親が存在して、それの下にある子を認識する→絶対的な経路

StatusFlag では後者の方法で、グローバル オブジェクトによって実現していました。
前者の方法は、まず「自分の親」をスマートに認識する必要があります。
クラスは継承されているなら継承元のことは認識出来ますが、
メンバとなっていると、自分を持っているクラスのことは認識出来ません。
無理矢理に親のポインタを自分が持つ手もあります（ある意味絶対的な経路）が、
それはそれでスマートじゃない気がします。

というか、そもそもこの分業体制自体、組み立てていくとどうしても相互依存してしまう予感です。
設計の仕方から慎重にならなければなりません。思い返すとここでもう迂闊でした。
コード上では他のクラスのメソッドをクラス ライブラリのように利用していますが、
これはライブラリではありません。ライブラリなら相互ではない依存があちこちにあります。
しかしあくまでも一方向の依存です。これはスマートなものであり、辿れば終わりがありますね。
しかしプログラムの実装となると別になって来ます。この方法を使うとまとまりがありません。

分業体制はオブジェクト指向がベースです。
作業をいくつかのオブジェクトに分担させてひとつのプログラムにする。
しかしその中で互いに強く依存してしまうとそれは分業という建前の助け合いになり、
関係が複雑にならざるを得ず保守が難しくなるのです。

じゃあ、せっかくのオブジェクト指向の利点を活かしながらどのような構造にしていけばよいのか。
まずそこからです。