構成について 序
ちょっと本気で考えてみる構成について。
構成を考える上で必要になってくるのって、どの観点で分けるかという前提だと思う。
考えるにしても実際に即した内容じゃないと考える価値もない。
という訳で実際の動作を想定した場合のアレこれについて考えてみます。
大まかなアプリケーションの動作というのは基本的に、
操作 → 動作確定 → 動作実行 → 処理確定 → 処理実行 → 描画確定 → 描画反映
という流れになると思います。
要するに、操作に対して動作があって、動作に応じて処理と描画がある。
MVCで考えるなら前半三つと確定部分がC、処理実行がM、描画反映がVの役割になってきますかね、と。
実際の成果物では確定動作までをCでやってるのにそのあと再度中間Controllerで状態管理して実行制御してたりする場合がある。
おかげで一つの画面を作ったり一つの処理作るために異常に多くのクラスを修正する必要が出てきたりする場合があります。
これってオブジェクト指向の旨味を完全に破棄してしまってる。
オブジェクト指向って本来、例えば処理を修正した時に別の部分に影響を出さないようにしようという指標では、と。
描画を修正するために処理を変更する必要がないようにしようということじゃないのか、と。
動作を追加する、とかそういう話になってくると全体に絡むのは仕方ないんですけどね。
追加じゃなくて修正という観点で見た場合に影響範囲が広くなるというのは間違いなくオブジェクト指向できてないというだけに思えて仕方ない。
というかオブジェクトの役割を整理しきれてないだけとも言える。
実際プログラマやってて萎えるソースコードというのは大抵が、『動けば良いじゃない』のノリで役割を無視して書かれた動かないソースコードです。
もしくは動くにしても想定外の動きをするとか。
それで金もらえるんだから良いよね、というところですが。
まあ、当然皮肉ですけども。
役割の整理ができてないから余計なクラス突っ込んだりする必要が出てくる。
そして影響範囲が肥大化していく。
一つの処理を修正して別の場所で別の処理にバグが出るようなプログラムってゴミでしかないでしょ、と。
高機能になればなるほど一つの処理、一つの描画のために必要なクラス数が増えて行くのは仕方ないと思うんですけどね。
かといって無制限に増やして良い訳じゃないんだぜ、と。
増えれば増えるほど後々の作業効率落ちるんだから。
と、愚痴はこれくらいにして明日はもうちょっと建設的な話にしますかね。
