mojix.org
ケント・ベック『実装パターン』（2008年） 実装パターンの６つの原則
ピアソン・エデュケーション - 実装パターン
http://www.pej-hed.jp/washo/2635.html
著：ケント・ベック（Kent Beck）
監訳：長瀬嘉秀、永田渉
訳：株式会社テクノロジックアート
発行：2008年12月20日
ページ数：208
判型：A5
税込価格：2,310円
ISBN10：4894712873
ISBN13：9784894712874
＜XPの提唱者ケント･ベック最新刊！
毎日のプログラミングにとことん役立つパターン集！＞
＜集められた77のパターンは、日々のプログラミング作業をこなし、読みやすいコードを書くためのものです。この新しいパターン集は、クラスや状態、振る舞い、メソッド、コレクション、フレームワークなど、開発のさまざまな問題に対処します。著者は、図表やストーリー、例題、エッセイをフル活用して、パターンを解明してゆきます。変数の命名から例外チェックまで、プログラミングのあらゆる問題を処理する解決法が、あなたにもきっと見つかるでしょう＞。
ケント・ベックの『実装パターン』という本（2008年）をいまごろ知り、読んでいるのだが、これは最高の本じゃないだろうか。
この『実装パターン』は、本棚では『デザインパターン』や『リファクタリング』の横に置かれるべき本だろう。しかし、この本は『デザインパターン』や『リファクタリング』よりもだいぶ小さいし、薄い。ベックの有名なＸＰ本と同じ版型で、同じくらいの厚さで、語り口も同じようにやわらかい。
内容は、案内ページにある目次を見れば、大体予想がつくと思う。「５章 クラス」「６章 状態」「７章 振る舞い」「８章 メソッド」あたりが、本書の中心だ。
ここでは、「３章 プログラミングの理論」にある「原則」を紹介したい。本書に収められている実装パターンをつらぬく原則は、以下の６つであるとのこと。
原則１） 結果の局所化
原則２） 繰返しの最小化
原則３） ロジックとデータの一体化
原則４） 対称性
原則５） 宣言型の表現
原則６） 変更頻度
それぞれ、解説の冒頭部分を抜き出してみよう。
原則１） 結果の局所化
＜変更の結果が１箇所にとどまるようにコードを構成しよう。「こちら」での変更が、「あちら」に問題を波及させるなら、その時変更のコストは劇的に上昇する。結果の局所化がほぼできているコードであれば、コミュニケーションは効果的になる。最初からコード全体の把握につとめなくてもよく、段階的に理解すればいいからだ。
変更のコストを低くとどめることが、実装パターンを行う一番重要な動機なので、結果局所化の原則は、多くのパターンにおいてその論拠の一部となっている＞。
原則２） 繰返しの最小化
＜結果の局所化に貢献する１つの原則は、繰返しの最小化である。同じコードが複数の場所にあった場合、そのうちの１つを変更すると、残りのすべても変更すべきか否かを判断しなければならなくなる。そうなるともはや、局所的な変更ではない。コードのコピーが増えれば増えるほど、変更のコストは増大するだろう＞。
原則３） ロジックとデータの一体化
＜結果局所化の原則から必然的に導き出されるもう１つの原則は、ロジックとデータを一緒にするという原則だ。ロジックと、ロジックが操作するデータは互いに近くに置くようにしよう。可能であれば同じメソッドか同じオブジェクトに、少なくとも同じパッケージに置くようにしよう。変更を行う際には、ロジックとデータは同じタイミングで変更しなければならないことが多い。これらが同じ場所にあれば、変更の結果も局所化が保てるだろう＞。
原則４） 対称性
＜対称性という原則も私は日常的に使用している。プログラムには対称性が多く存在する。add()メソッドにはremove()メソッドが対になるし、あるメソッドのグループはすべて同じ引数を取るし、あるオブジェクト内のフィールドはすべて生存期間が同じである。対称性を特定し、明確に表現すれば、コードは読みやすくなる。読む側としても対称性の片側をひとたび理解すれば、もう片側もすぐに理解できるだろう＞。
原則５） 宣言型の表現
＜意図についてはできるだけ宣言型で表現するというのが、実装パターンの背後にあるいま１つの原則である。命令型プログラミングは強力で柔軟だが、実行される流れを追いながら読まなければならない。プログラムの状態モデル、制御とデータのフローモデルを頭の中に描かなければならないのである。プログラム内において、順序や条件分岐がなく、純然たる事実に似た部分に対しては、コードが宣言的に書かれているほうが、読みやすくなる＞。
原則６） 変更頻度
＜最後の原則は、同じタイミングで変更されるロジックやデータは同じ場所に置き、変更されるタイミングが異なるロジックやデータは分けておくというものだ。このような変更頻度は時間的な対称性として現れる。変更頻度原則は、プログラマが行う変更に当てはまる場合がある。たとえば、税額計算のソフトウェアを作成する場合、一般的な計算ロジックのコードと、年ごとに固有なコードを私なら分離するだろう。それぞれ変更されるタイミングが異なるからだ。翌年変更を行うときには、前年から変更していないコードも間違いなく動作し続けるようにしたい。変更頻度の異なるコードを分けておけば、変更の結果が局所化されるという自信が持てる＞。
このような感じで、やわらかい語り口ながらも、ひたすら本質的なことだけが述べられていくのだ（文章だけでなく、Javaのサンプルコードと、説明の図もたくさんある）。
この６つの原則はどれも重要なものだが、個人的には「対称性」が特に印象的だ。これは、よい文章を書くときの原則としても通じるだろう。
ベックは本書で、「意図がわかる」「読みやすい」という言い方をしょっちゅうしている。これはプログラミングの話なのだが、一般の文章を書くときの心得とまったく同じである。
ソフトウェアは、単に動けばよいというものではない。そのソースコードは、よい文章と同じように、人間に向けて、わかりやすく書く必要があるのだ。
関連エントリ：
Pythonでデザインパターン
http://mojix.org/2012/08/10/python-patterns
プログラマというのは物書きである
http://mojix.org/2010/03/16/programmer_monokaki
わかりやすいものを作る能力は、ロジックではなく「美」に属する能力
http://mojix.org/2009/03/23/wakariyasui_beauty
http://www.pej-hed.jp/washo/2635.html
著：ケント・ベック（Kent Beck）
監訳：長瀬嘉秀、永田渉
訳：株式会社テクノロジックアート
発行：2008年12月20日
ページ数：208
判型：A5
税込価格：2,310円
ISBN10：4894712873
ISBN13：9784894712874
＜XPの提唱者ケント･ベック最新刊！
毎日のプログラミングにとことん役立つパターン集！＞
＜集められた77のパターンは、日々のプログラミング作業をこなし、読みやすいコードを書くためのものです。この新しいパターン集は、クラスや状態、振る舞い、メソッド、コレクション、フレームワークなど、開発のさまざまな問題に対処します。著者は、図表やストーリー、例題、エッセイをフル活用して、パターンを解明してゆきます。変数の命名から例外チェックまで、プログラミングのあらゆる問題を処理する解決法が、あなたにもきっと見つかるでしょう＞。
ケント・ベックの『実装パターン』という本（2008年）をいまごろ知り、読んでいるのだが、これは最高の本じゃないだろうか。
この『実装パターン』は、本棚では『デザインパターン』や『リファクタリング』の横に置かれるべき本だろう。しかし、この本は『デザインパターン』や『リファクタリング』よりもだいぶ小さいし、薄い。ベックの有名なＸＰ本と同じ版型で、同じくらいの厚さで、語り口も同じようにやわらかい。
内容は、案内ページにある目次を見れば、大体予想がつくと思う。「５章 クラス」「６章 状態」「７章 振る舞い」「８章 メソッド」あたりが、本書の中心だ。
ここでは、「３章 プログラミングの理論」にある「原則」を紹介したい。本書に収められている実装パターンをつらぬく原則は、以下の６つであるとのこと。
原則１） 結果の局所化
原則２） 繰返しの最小化
原則３） ロジックとデータの一体化
原則４） 対称性
原則５） 宣言型の表現
原則６） 変更頻度
それぞれ、解説の冒頭部分を抜き出してみよう。
原則１） 結果の局所化
＜変更の結果が１箇所にとどまるようにコードを構成しよう。「こちら」での変更が、「あちら」に問題を波及させるなら、その時変更のコストは劇的に上昇する。結果の局所化がほぼできているコードであれば、コミュニケーションは効果的になる。最初からコード全体の把握につとめなくてもよく、段階的に理解すればいいからだ。
変更のコストを低くとどめることが、実装パターンを行う一番重要な動機なので、結果局所化の原則は、多くのパターンにおいてその論拠の一部となっている＞。
原則２） 繰返しの最小化
＜結果の局所化に貢献する１つの原則は、繰返しの最小化である。同じコードが複数の場所にあった場合、そのうちの１つを変更すると、残りのすべても変更すべきか否かを判断しなければならなくなる。そうなるともはや、局所的な変更ではない。コードのコピーが増えれば増えるほど、変更のコストは増大するだろう＞。
原則３） ロジックとデータの一体化
＜結果局所化の原則から必然的に導き出されるもう１つの原則は、ロジックとデータを一緒にするという原則だ。ロジックと、ロジックが操作するデータは互いに近くに置くようにしよう。可能であれば同じメソッドか同じオブジェクトに、少なくとも同じパッケージに置くようにしよう。変更を行う際には、ロジックとデータは同じタイミングで変更しなければならないことが多い。これらが同じ場所にあれば、変更の結果も局所化が保てるだろう＞。
原則４） 対称性
＜対称性という原則も私は日常的に使用している。プログラムには対称性が多く存在する。add()メソッドにはremove()メソッドが対になるし、あるメソッドのグループはすべて同じ引数を取るし、あるオブジェクト内のフィールドはすべて生存期間が同じである。対称性を特定し、明確に表現すれば、コードは読みやすくなる。読む側としても対称性の片側をひとたび理解すれば、もう片側もすぐに理解できるだろう＞。
原則５） 宣言型の表現
＜意図についてはできるだけ宣言型で表現するというのが、実装パターンの背後にあるいま１つの原則である。命令型プログラミングは強力で柔軟だが、実行される流れを追いながら読まなければならない。プログラムの状態モデル、制御とデータのフローモデルを頭の中に描かなければならないのである。プログラム内において、順序や条件分岐がなく、純然たる事実に似た部分に対しては、コードが宣言的に書かれているほうが、読みやすくなる＞。
原則６） 変更頻度
＜最後の原則は、同じタイミングで変更されるロジックやデータは同じ場所に置き、変更されるタイミングが異なるロジックやデータは分けておくというものだ。このような変更頻度は時間的な対称性として現れる。変更頻度原則は、プログラマが行う変更に当てはまる場合がある。たとえば、税額計算のソフトウェアを作成する場合、一般的な計算ロジックのコードと、年ごとに固有なコードを私なら分離するだろう。それぞれ変更されるタイミングが異なるからだ。翌年変更を行うときには、前年から変更していないコードも間違いなく動作し続けるようにしたい。変更頻度の異なるコードを分けておけば、変更の結果が局所化されるという自信が持てる＞。
このような感じで、やわらかい語り口ながらも、ひたすら本質的なことだけが述べられていくのだ（文章だけでなく、Javaのサンプルコードと、説明の図もたくさんある）。
この６つの原則はどれも重要なものだが、個人的には「対称性」が特に印象的だ。これは、よい文章を書くときの原則としても通じるだろう。
ベックは本書で、「意図がわかる」「読みやすい」という言い方をしょっちゅうしている。これはプログラミングの話なのだが、一般の文章を書くときの心得とまったく同じである。
ソフトウェアは、単に動けばよいというものではない。そのソースコードは、よい文章と同じように、人間に向けて、わかりやすく書く必要があるのだ。
関連エントリ：
Pythonでデザインパターン
http://mojix.org/2012/08/10/python-patterns
プログラマというのは物書きである
http://mojix.org/2010/03/16/programmer_monokaki
わかりやすいものを作る能力は、ロジックではなく「美」に属する能力
http://mojix.org/2009/03/23/wakariyasui_beauty