Implementation Patterns
お勉強
最新更新日時: 2009年11月09日 18時20分
このフォルダのページビュー: 5690
| 1. イントロダクション |
|
さて、一緒に始めましょうか。私の本を手に取っちゃいましたね（もう君の本です）。既にコードを書いた事あると思うけど、多分既に、経験上自分自身のスタイルってのが出来てると思います。 この本のゴールは、コードを通して自分の意図を伝えるのを助ける事です。最初はプログラミングとそのパターンの概要から（2～4章）。残りの部分は（5～8章）は、Javaの機能を使って読みやすいコードを書く方法についての、短いエッセイとパターンが続きます。最後の締めくくりは、アプリケーションでなくてフレームワークを書く場合、この本のアドバイスをどうモディファイすればいいかについての章になります。徹頭徹尾、この本はコミュニケーションを向上させるプログラミングテクニックについてフォーカスしてます。 コードを通したコミュニケーションには、いくつかのステップがあります。第一ステップは、プログラミングの最中に気をつけるようになる事でした。私が最初に実装のパターンを書き始めてから、何年かプログラミングを続けてますが、それでこんな発見をして驚きました---プログラミングの際に自分にとってはスムーズにさっと決めた事であっても、あるメソッドがなぜそんな名前でなきゃいけなかったのか、とか、あるちょっとしたロジックがなぜこのオブジェクトにあるのか、とかを人に説明出来ないのです・・・。コミュニケーションへの最初のステップは、まずはスローダウンして、自分が何を考えていたのか自覚して、直観でコーディングしたつもりになるのをやめる事です。 第二のステップは、他の人の重要性を認める事です。プログラミングだけして満足してるのは、自己中心的です。コミュニケートしやすいコードが書く以前に、他の人が自分と同じくらい重要なんだと信じる必要がありました。プログラミングというものが、一人の人間とひとつのマシンの中でやりとりが閉じてるなんてことは、殆どありません。他の人について考える事は、意識して実践すべきです。 以上が第三のステップのきっかけになります。自分の考えをおてんとさんと新鮮な空気のもとにさらして、他の人には自分と同様に存在意義があるのだと認めたら、次には、実践の中で自分の新しい視点を示す必要がありました。ここに実装パターンをプログラムに意識的に使う事になります。他の人のため、また同様に自分のためにも。 この本は、使えるトリックが説明されてるので、厳密に技術書として読めます。ですが、それ以上のもっとずっと多くの事がそこには書かれていると云っても過言ではありません。少なくとも私にとっては。 パターンの章をパラパラとめくると、技術的な具体例が書いてあります。パターンを使いたくなったらその章を読むというのも一つの効果的な勉強の仕方です。「just-in-time」で読む場合、5章まで飛ばして終わりまでざっと読むのがお薦めです。その時はプログラミング中にこの本をそばに置いておきましょう。いくつもパターンを適用した後に、そのパターンの背後にある哲学的背景についての概要に戻ればよいでしょう。 もしこの本の内容を徹底的に理解したいなら、最初から通して読んで下さい。でも、他の私の本と違って、各章は結構長いので、端から端まで読むのには集中力が必要だと思います。 この本に書かれてる事は、大体パターンとして集められたものです。プログラミング上の決断というのは、今までしてきた他の決断とほとんど変わりありません。プログラマーとしてのキャリアの中で、何万という変数に名前をつけて来たでしょう？変数名をつけるのに、全く新しい方法なんて思い付かないでしょう。普通一般のネーミングのルールでも同じです。変数を読む人に、その目的、タイプ（型）、寿命（スコープ）を伝えなきゃいけないし、読みやすい名前にしなきゃいけないし、書きやすくてフォーマットしやすい名前にしないといけない。この一般ルールに特定の変数の仕様を適用してみれば、生産性の高い名前が思い付くはずです。変数名のつけ方はパターンの例のひとつです。このルールは、別の違う名前をつける場合でも繰り返し使えます。 パターンを表現するのには、しばしば違う方法が取られると思います。理屈っぽいエッセーの形だったり、図表だったり、物語形式だったり、コードサンプルだったり。パターンの詳細をお固いフォーマットに押し込めないで、それぞれのベストだと思うやり方で説明するようにしました。 この本には77の明示的に名前の付いたパターンがあり、それぞれが読みやすいコードを書くという局面をカバーしています。おまけに、もっと小さいパターンや、ついでに書いたパターンの断片がたくさんあります。将来コードを読んだ人が、そのコードが何をサポートしようとしているのか判るように、毎日のコーディングでの何をすべきかを提示すること、それがこの本での私の目的です。 この本はデザインパターン本とJava言語マニュアル本のちょうど間に位置します。デザインパターンというのは、開発中の一日の内の何回かの出来ごとについての話です。例えば、典型的なオブジェクト同士のインタラクションを規定したりと云った事です。実装パターンはプログラミング中に数秒ごとに適用します。Java言語マニュアルは、Javaで何が出来るのかを知りたい場合にはよいですが、 なぜその方法を使うか、そのコードを読んだ人がどう判断するか、などは判りません。 私がよく知ってるトピックにこだわるというのがこの本を書く上でのポリシーです。例えば、並行処理についてはここでの実装パターンには盛り込まれていません。並行処理が重要でないという事ではなくて、自分が語れる事があまりないからです。私の並行処理の対処する場合、いつも、アプリケーション内でなるたけ同時並行する部品を孤立化させておいてます。それで大概上手い事行ってるので、さして説明する程の事でもありません。並行処理についての実践を知りたい場合は、「Java Concurrency in Practice」みたいな本をお薦めします。 あと、ソフトウェアプロセスについての記述も盛り込まれてません。コードを通じたコミュニケーションについての話は、長いサイクルの終わりに書かれたコードか、コケるテストが書かれた数秒後になら役に立ちます。 また、Javaの最先端についての話もありません。私は技術に関しては保守的な傾向にあります。なぜなら、新しい機能を限界までプッシュして燃え尽きちゃう事が、本当によくあったからです（お勉強ならとてもいい事ですが、殆どの開発にとってはリスキーすぎます）。なので、この本にはJavaの平凡なサブセットしかありません。もしJavaの最新機能を使いたいと思ったら、他の資料にあたって下さい。 ◆ツアーガイド この本は、七つの大きなセクションに分かれています（図表1.1)。こんな感じです。 |
| 2. パターン |
|
プログラミングでの判断の多くは独特。WEBサイトをプログラミングしようとするのと、ペースメーカーを作ろうとするのではもう全然違う。だがしかし、その判断がより純粋に技術的になるにつれて、どっかで見知ったような感じになる。このコード書かなかったっけ？平凡な繰り返し作業の時間が減って、プログラマーが本当に大事な問題を解決する事にもっと時間を割けるようになったら、プログラミングはもっと効果的なものになる。 殆どのプログラムは、ある法則に準じている。
パターンはこの共通点を基にしている。例えば、プログラマーは皆、繰り返し処理を構築する方法を決めないといけない。ループをどう書こうかなあと考えてる時までに、ドメインに特化した問題の殆どは解決されて、純粋に技術的な課題 --- ループは読みやすくて、書きやすくて、検証しやすくて、改良しやすくて、効率的でないといかん --- だけが残されているはずである。 この懸念のリストがパターンの始まりだ。この上にあげた制約条件や圧力が、プログラム内の全てのループを、どう書こうかなあという判断に影響を及ぼす。この力は、予想した通り、再帰する。パターンがパターンであらしめる感覚、それが力のパターンだ。 ループを書く合理的な方法は少ない。各方法は、この制約条件の間でそれぞれ違う優先順位を持っている。もしパフォーマンスが重要なら、このループの方法を使うのがいいだろうし、もし修正しやすさが重要なら、違う方法がいいだろう。 |
