粛々と進めているTQA開発ですが、サーバ側のメインファイルのコード量が膨れてきたので、モジュール分割しました。結果、どのモジュールに割り当てたら良いのかわからない関数が出たり、追加の参照インターフェイスが必要になったり…。コードのスパゲッティ度が如実に浮かび上がりました。まあ、手でほどける程度なので、良かったですけど。
こうして、新規にインターフェイスを増やしてまで、モジュール分割することの利点の1つは、改造時の影響範囲を限定できることです。実際、今回は少し大きい改造が入るため、地ならしとして分割を行いました。
こうしたモジュール分割の話は、基本情報処理技術者試験などで目にしますが、どのタイミングで、どの粒度で分割するのか、実際にやってみるといろいろ悩ましいですね。
ちなみに、分割作業の状況は、ようやくモジュール単位でコンパイルが通り始めたところです。またリンクでいっぱい出るんだろうなあ…
コメント
こんばんは☆
上手なモジュール分割…これは悩ましいテーマですよね。
私の方も初期検討時にちゃんと設計しなかったばっかりに、気がついたら基本情報技術者
で言うところのネットワークモデルなオブジェクト構成になっていました。
この辺の知識はプログラミング経験が効いてきますよね。
慣れないうちは参照を持ち過ぎて、強引な横方向の呼び出しをしまくったりとか
（階層構造だと縦方向が基本ですね）、オブジェクト間でお互いの参照を持ち合ったり
とか…（C++だとコンパイルエラー）。
システム開発だとこの辺りは設計しやすそうですが、柔軟なロジックが要求される
ゲーム開発だとまた難しくて・・・この辺りのプロのゲームプログラマー達の技を
一度見てみたいなぁと思うところです。
コンパイルエラーを撲滅させた後の、実際の動作確認が大変そう…。
予期せぬ出来事がきっと３件は起きると予想してみましたがはてさて(^◇^;)。
では開発がんばってください～。
おはようございます。本来は設計のさいに、きちんと先を見越した構成にするのが理想的ですが、現実にはそうもいかず。というわけで、少しでも変更に強い形にするしかないのかなあ、と思います。
オブジェクト指向は、何をオブジェクトとして定義するかの判断が、なかなか難しそうです。このへんはセンスなのでしょうかね～。うちは、今回ほとんどを静的クラスにしてしまい、オブジェクトが出てこないような形に…。もうオブジェクト指向は無視状態です（ぉ
動作確認は、実行コード自体は同じなので、特に問題ないかなあ、と踏んでいます。とはいえ、予想外のところから出てくるのが、バグなのですけど。。ただ、その手前のリンク作業では、3件と言わず十数件のエラーが出そうです＾-＾；