Insider.NET 掲示板の「質問」を見ていて思うことです。半分か、それ以上の質問に対して、補足が求められています。
「何がしたいの？」「何がしたいのかわからん」「で、どうしたいのでしょう？」「何がわからないのでしょう？」
いったい、どうしてでしょう？
私が思うのは、「考える順序の問題」なのかなぁ？
私が新人の頃は、「まず、設計しろ」といわれました（ここでの「設計」は、「フローチャートを描く」レベルの設計）。でも今は、短納期ということもあり、いきなりコーディングを始めるのが主流のようです。
かくいう私も、今はいきなりコーディングが主流です。でも、私は、頭の中に様々なライブラリが出来ています。まぁ、そのせいで、他の考え方が出来なくなるというのもありますが。←これ重要
とはいえ、ややこしいと思ったら、まず設計しています。行き詰まったら（国語的注：「煮詰まる」は「完成する」の意味合いが強い）、設計に戻ります。
なぜ？
自分の考えを整理し、「何をするべきだったのか」からずれていないか、確認するためです。
そこで、私がコーディングのための設計をする場合に、何を考えるか、メモしておきます。
私はまず、最終目標を確認します。「何が出来なければならないのか」。もしここで、「何と何が出来なければならない」になれば、この２つの「何」を、別々の関数／メソッドに分解します。これは、ひとつの関数／メソッドの行数を短くすると共に、その時に考えなければならないことを単純にするためでもあります。
これが、ひとつのポイントかと思います。聖徳太子のように、複数の人の話を聞き分け、ほぼ同時にそれに対する回答を考えることが出来る人は、まずいないでしょう。同じように、複数の「何か」を考えるのは、難しいのではないでしょうか。
目標が決まったら、「それをするためには、何が必要か」を考えます。これは「何と何と何が必要」と、「何」が複数発生するはずです。この、「必要なもの」が、新しい目標になることもあります。
ある程度数をこなすと、この「目標」に対する「手順」が形式としてたまります。これが「俺フレームワーク」となるわけです。
また、このときに考えるのは「コード」ではありません。あくまで、「必要なもの」です。その必要なものを揃えるためにどうするか、と言うところが、コードになります。しかし、この「コード」は、「俺フレームワーク」には入っていません。
実装と手順を分けておくこと。これによって、他の言語を使わなければならなくなっても、そんなに慌てないで入っていくことが出来ます。
さて、「なんか、足りなくない？」と思われた方。その通りです。これは、オブジェクト指向以前、私が 1990 年から 1996 年くらいに、SunOS 上で C 言語をさわっていたときの話です。なので、オブジェクトの切り分けについて、触れていません。しかし、あるクラスの１つのメソッドを実装するためには、今も同じではないでしょうか。
で、オブジェクトの切り分けについて書きたいわけですが。
すみません。書けるほど、理解できていません。誰かお願い（ぉぃ
投稿日時 : 2006年9月27日 22:09