日々の破片

_ ファンクションとプロシージャ

後先を考えてない思いつきだから真に受ける必要はないが、もしかしたら、ファンクションの存在が混乱とかバグとかの元なんじゃなかろうか？

staticなユーティリティを除いて、すべてプロシージャとして実装させることで、例外は例外として使わざるを得なくなるし、責務は分担せざるを得なくなるんじゃないかな。

思えば良き構造化プログラミングスタイルでは、プロシージャとしてサブルーチンは組まれるものだ。ダメパターンってのはにもかかわらずファンクションとして実装してしまい（しかし戻り値を返せないから）グローバル変数を使いまくるってのが第1だ。第2は例外がないから深き淵から浮かび上がるためにグローバルな処理制御フラグが必要になる点だけど。（もちろん、インスタンスが無いから微妙なわけだが、実際にはトップレベルからインデックスを回してやるというような方法で個々のプロシージャが利用するデータ毎にリデファインして用意しておけば、実際にはそれほどひどいことにはならないし、そんなことをしなくてもいずれにしろあらかじめバウンダリーは設計しておくものだ。というか、もしひどいことになれば銀行の第3次オンラインは存在できなかったことになる）。それにプロシージャ主導で設計すると、エンドゥーテストが必須になるということも実は良いことなのではなかろうか？

と考えるとファンクション主導の出来の悪い（ask, ask, ask, accs関係ないか）オブジェクト指向な実装は、ピュアな構造化された実装よりも悪いことのほうが多いということに見える。COBOLというよりも、Windows3.0〜3.1時代のVBみたいだ（もちろん、VBはファンクションとプロシージャの区別を明示的に持つ優れた構造化言語だから、実際には使われ方の問題ということでもある）。さらにさかのぼると、デフォルトでintが戻ったCが元凶かも？

元凶は入門書なのかな？ 読んでないからわからないが。でも、どうして呼んで得て見てこねくり回してまた与えて得て……という組み立て方をするんだろう？ どこかでそういうもんだと習ってるからじゃなかろうか。

フローチャートで「処理」を記述するとそうなりがちだから、それは原因の一つだろう（これは、気付いているのでJavaの処方箋で指摘している）。とは言えアルゴリズムを記述するのには向いているわけでそれは現在でも事実だと思うが、もう細かいアルゴリズム（ソートとかマージとかサーチとか）を考えることも通常の分野では無いわけだから、さっさと捨ててしまうことも必要だろうな。特許の説明書くときには有用な記法らしいけど。

あとはなんだろう？ Hello worldは、printfとかSystem.outにtellするだけだから別段悪くはない。その次あたりだな。というと演算をするからローカル変数が出てくるのかも。ローカル変数を教えなければどうかな？ askした結果をしまうものを最初のうちに見せてしまうから、手元に持って来たくなるかも。収集癖はすべての動物の本能だし（と思う。リスは団栗を集めて地面に埋める。で忘れてしまう。できの悪いプログラムのようだ。もっとも、おかげで次の木が生えるわけでそれは良いことだったりするけど、不用変数への代入はコンパイラが捨てられるだけでろくなものではない）でもローカル変数を見せないとフィールドに入れられたりするかも。それじゃ逆効果だ。ということは変数を無いことにしてしまったらどうだろうか？ それはさすがに無理か。

結局、カタだな。そう言えば角谷さんのカタ入門はどうなったんだろうか？ と突然思い出したり。

呼び出しのバウンダリーが明確だと死んだ時の解析もしやすいとか、そういったことを示しながら進めるというのはどうだろうか？ でも、現実的にはならなかったり。でもそれは心配ないはずだ。

朱に交われば赤くなる。水は方円の器に従う。

トランザクションスクリプトのほうが向いていれば、そっちで作るのは簡単だ。だから、逆に概念的にはどうかはわからないが、実装的には逆に単純（シンプル）な、ドメインモデルをこそ最初に教えるべきではないか。