void GraphicWizardsLair( void ); // 設計書コーディングとアジャイルとより。
「設計書コーディング」というキーワードと、naoya さんの「プログラミングは詳細に設計された設計書を実際の形に落とし込むための手段に過ぎないとか」と言ったフレーズに(つまり設計書の存在)、「静的型付け」がバインドされたようなニュアンスになっているところに(ありがちな話ではありますが)引っかかったりします。
両社には相関関係はない、というと御幣がありますが、静的型付けは設計書コーディングのためのものではないことは明らかです。
が、世間的には静的型付けについて、「設計の正しさの検証可能性を上げるためのもの」と認識されてしまっている恐れはあります。悲しいことに。
私的には、型を宣言するのは(いま思いつくまま書いてるので正確ではないと思いますが)、コンテキストを明文化し、設計をしやすくし、後で読みやすくするため、といったところです。
前者の意義も付属的についてきますし、それも重要な利点ですが、それが目的だとは思っていないです。サボって書いてもそこそこの可読性を確保できるのは便利だったりしますし、(interface により)応答可能性を宣言できるというのは(作成中/後の可読性両方の観点で)特に重要と思います(*)。
型を宣言しているからインスペクションが楽になって、利用者が実際に利用できる機能をすぐに一覧できるようになっています(eclipse など)。perl や ruby だと、できるけどちょっと面倒そう(動的にメソッドを付与とかしてるとほとんど不可能)。
Java で非設計書コーディングをすると、かなり楽だったりするんですが、みんなこのへんどう思ってるんでしょ？興味深いなぁ。
*:
Java が万全とは思いませんけどね。inner class ですら冗長で気軽にクロージャ的使い方がしにくいところとか。それに、「呼んでみなきゃ分からない」を「とりあえず呼んでみることができる」と考える非静的型の考え方もまったく否定する気はないです。自分にはあまり向かないけど^^;
私のプログラミング手法は、大雑把にいうと、「とりあえず呼ぶコードを書く」です。そうすると、(その時点でオブジェクトの必要性はもう定まってるのは前提)呼ばれる側を書かなきゃならないことが静的に分かるので、後で書かなきゃとか意識せずに思考を進めることができるんです。インターフェイス指向と呼んでますが、こういうインターフェイスに応じることができる役割が必要だな、というのをトップダウンで考えていく感じです。
