オブジェクト指向のソースを読むのが難しい理由
ダラダラ書かない予定だよ。ざっくり行くよ。あと、分かってる人には当たり前な事だと思うよ。
あるクラスについて知りたかったら、まずその基底クラスを知れ
例えば、Integerクラスについて知りたいと思ったら、Integer.java だけを読んでいてはダメだ。確かに「Integerに特化した責務・構造・操作」は読み取れるかもしれないが、数値としての基本的な責務・構造・操作はNumberに書かれている。それを読まずして、Integerが保つ数値という一面を知ることはできない。Integer.javaには「Integer - Number」*1の情報しか書いてないのだよ。差分プログラミング。
さらに、忘れちゃいけない。Object.javaを読め。全ての道は暗黙的にObjectにつながっている。Objectを知らずしてJavaのクラスを知る事は絶対にできない。Objectなんて、みんな「知った気」になってるんじゃなかろうか*2。あと、クラスのextends関係だけではなく、当然インターフェイスのimplementsも必須。
ソースを読むのが難しいのは、出来るだけソースを読みたくないから「そのファイルだけに読む範囲を絞ろう」という甘えがあるからだ。知りたいクラスが使用*3しているクラスをも知るに越した事はないが、時間的制約もあるだろうから、せめて基底は押さえておく、という方針が良いのではないかとおもっちょる。
あるクラスについて知りたかったら、まずそのドキュメントを読め
トークンの並びを理解する前に、そのトークン列が何を達成しようとしてるのかを知らないと。というわけで、最初に読まなきゃいけないのは、実は「コード」じゃなくて「ドキュメンテーションコメント(Javadoc)」だ。
当然、メソッドやフィールドについているコメントも重要だが、もうほんとに最初に読むのは「型（classとかinterface等)に対するドキュメント」ね。結構分かった風になっちゃってるから飛ばすんだよね、みんな。
例えばStringBuilder。みんな、これを「文字列(string)組み立て(build)屋(er)」だと思ってるでしょ。まぁ、間違っちゃいないし、初心者連載では俺もそう説明しているんだけど。しかし、このクラスの第一義は「可変(mutable)な、文字(character)の、列(sequence)」だ。「屋(er)」を表すんじゃなくて、「列(sequence)」を表すクラスだったりする。Javadoc見りゃ1行目に書いてあることさ。
（あとはStringをネタにして深淵に潜り込むのもよし。これは本当に「文字列」か？ 文字(character)の列(sequence)ならば、CharSequenceではないのか？ そういう型もあるぞ？ とか言って。あとはもうどうにでもしてクダサイ。俺はめんどくさいので燃料だけ投下して離脱しますw）
で、まぁこの例だと「だから何だ」になりかねないが。みんな名前だけで仕様と責務を想像して、その上で実装読んでたりしない？ じゃなくて、ドキュメントで仕様と責務を把握した上で実装読むんだよ。
ソースを読むのが難しいのは、「英語を読みたくない」という甘えがあるからだ。英語ドキュメント読むよりトークン列を読むほうが楽だと、みんな思っているんだよね。僕にはわけがわからないよ。
