次期グラフシミュレータ（GraphSim3）に関する考察（６）

６回目です．だれだれです．疲れてきたので，この辺で一回止めておきます．
前回は，４番目と５番目について検討した．今回は，６番目と７番目について述べる．

不必要なコンストラクタ
入出力関数でのポート指定
入出力データの扱いづらさ
無駄なtry{}catch{}構文
InterruptedExceptionの記述
ステートマシンの分かりづらさ
DefaultFunctionalModule

ステートマシンの分かりづらさ

手続き型言語なので仕方がないといえば仕方がない問題点．ステートマシンを記述するためには，「ステートを保持する変数」＋「switch-case」文を使って，ガリガリステートを記述しなければならない．これは，一般的な手続き型言語と同じ．
で，なぜ問題かというと，ＰＣＡの機能回路はステートマシンにより記述される場合が多い．とくに，ストリームの並び替えや，ストリームのパターンマッチングなどが多い．どれくらい多いかと言われると数字を出せないので困るが，本当に割合的に多い．
割合的に多ければ，それらにマッチした記述方法を提供しても良いのではないかというのが，いまの考え．だから，ある特定のステートマシンについては，特化した記法を導入することで，ステートマシンの分かりづらさを解消しようと言うこと．

DefaultFunctionalModule

いちいちこれを継承するのがだるい．あと，継承してしまうことで，Java唯一の継承ルートを潰してしまうのが勿体ない．
どういうものが理想か．一番の理想は，Runnableのような機構を導入することだ．Runnableは，継承を消費することなく，Thread処理を記述することができる．では，なぜ現状ではそれを実現できないのか．一重に名前空間の問題である．read/writeメソッドをどこから引っ張ってくるのかという問題を解消できない限り無理．
Runnableを実装するクラスが単独で記述されるとき，外部の名前空間を用いない場合，もしくはインスタンスを生成した後に，何らかの方法で外部から情報を与えるようにプログラムを書く．それが面倒なときは，インナークラス，もしくは無名クラスとすることで，コンテキストに存在する名前空間にアクセスする．
read/writeメソッドは，その動作はコンテキストに依存する．そのため，コンテキスト情報を何らかの方法で与えなければならない．現状では，それをDefaultFunctionalModuleが行っていると言うわけ．
これをなくすことができれば，継承ルートを空けることができて，ハッピーになれそう．だから，問題点．ここまで来ると，私の求める美しさにのみ依存した問題っぽい雰囲気もないことはないけど...