2012.11.21
ケント・ベック『実装パターン』(2008年) 実装パターンの6つの原則
ピアソン・エデュケーション - 実装パターン
http://www.pej-hed.jp/washo/2635.html



著:ケント・ベック(Kent Beck)
監訳:長瀬嘉秀、永田渉
訳:株式会社テクノロジックアート
発行:2008年12月20日
ページ数:208
判型:A5
税込価格:2,310円
ISBN10:4894712873
ISBN13:9784894712874

<XPの提唱者ケント・ベック最新刊!
毎日のプログラミングにとことん役立つパターン集!>

<集められた77のパターンは、日々のプログラミング作業をこなし、読みやすいコードを書くためのものです。この新しいパターン集は、クラスや状態、振る舞い、メソッド、コレクション、フレームワークなど、開発のさまざまな問題に対処します。著者は、図表やストーリー、例題、エッセイをフル活用して、パターンを解明してゆきます。変数の命名から例外チェックまで、プログラミングのあらゆる問題を処理する解決法が、あなたにもきっと見つかるでしょう>。

ケント・ベックの『実装パターン』という本(2008年)をいまごろ知り、読んでいるのだが、これは最高の本じゃないだろうか。

この『実装パターン』は、本棚では『デザインパターン』や『リファクタリング』の横に置かれるべき本だろう。しかし、この本は『デザインパターン』や『リファクタリング』よりもだいぶ小さいし、薄い。ベックの有名なXP本と同じ版型で、同じくらいの厚さで、語り口も同じようにやわらかい。

内容は、案内ページにある目次を見れば、大体予想がつくと思う。「5章 クラス」「6章 状態」「7章 振る舞い」「8章 メソッド」あたりが、本書の中心だ。

ここでは、「3章 プログラミングの理論」にある「原則」を紹介したい。本書に収められている実装パターンをつらぬく原則は、以下の6つであるとのこと。

原則1) 結果の局所化
原則2) 繰返しの最小化
原則3) ロジックとデータの一体化
原則4) 対称性
原則5) 宣言型の表現
原則6) 変更頻度

それぞれ、解説の冒頭部分を抜き出してみよう。

原則1) 結果の局所化

<変更の結果が1箇所にとどまるようにコードを構成しよう。「こちら」での変更が、「あちら」に問題を波及させるなら、その時変更のコストは劇的に上昇する。結果の局所化がほぼできているコードであれば、コミュニケーションは効果的になる。最初からコード全体の把握につとめなくてもよく、段階的に理解すればいいからだ。
 変更のコストを低くとどめることが、実装パターンを行う一番重要な動機なので、結果局所化の原則は、多くのパターンにおいてその論拠の一部となっている>。

原則2) 繰返しの最小化

<結果の局所化に貢献する1つの原則は、繰返しの最小化である。同じコードが複数の場所にあった場合、そのうちの1つを変更すると、残りのすべても変更すべきか否かを判断しなければならなくなる。そうなるともはや、局所的な変更ではない。コードのコピーが増えれば増えるほど、変更のコストは増大するだろう>。

原則3) ロジックとデータの一体化

<結果局所化の原則から必然的に導き出されるもう1つの原則は、ロジックとデータを一緒にするという原則だ。ロジックと、ロジックが操作するデータは互いに近くに置くようにしよう。可能であれば同じメソッドか同じオブジェクトに、少なくとも同じパッケージに置くようにしよう。変更を行う際には、ロジックとデータは同じタイミングで変更しなければならないことが多い。これらが同じ場所にあれば、変更の結果も局所化が保てるだろう>。

原則4) 対称性

<対称性という原則も私は日常的に使用している。プログラムには対称性が多く存在する。add()メソッドにはremove()メソッドが対になるし、あるメソッドのグループはすべて同じ引数を取るし、あるオブジェクト内のフィールドはすべて生存期間が同じである。対称性を特定し、明確に表現すれば、コードは読みやすくなる。読む側としても対称性の片側をひとたび理解すれば、もう片側もすぐに理解できるだろう>。

原則5) 宣言型の表現

<意図についてはできるだけ宣言型で表現するというのが、実装パターンの背後にあるいま1つの原則である。命令型プログラミングは強力で柔軟だが、実行される流れを追いながら読まなければならない。プログラムの状態モデル、制御とデータのフローモデルを頭の中に描かなければならないのである。プログラム内において、順序や条件分岐がなく、純然たる事実に似た部分に対しては、コードが宣言的に書かれているほうが、読みやすくなる>。

原則6) 変更頻度

<最後の原則は、同じタイミングで変更されるロジックやデータは同じ場所に置き、変更されるタイミングが異なるロジックやデータは分けておくというものだ。このような変更頻度は時間的な対称性として現れる。変更頻度原則は、プログラマが行う変更に当てはまる場合がある。たとえば、税額計算のソフトウェアを作成する場合、一般的な計算ロジックのコードと、年ごとに固有なコードを私なら分離するだろう。それぞれ変更されるタイミングが異なるからだ。翌年変更を行うときには、前年から変更していないコードも間違いなく動作し続けるようにしたい。変更頻度の異なるコードを分けておけば、変更の結果が局所化されるという自信が持てる>。

このような感じで、やわらかい語り口ながらも、ひたすら本質的なことだけが述べられていくのだ(文章だけでなく、Javaのサンプルコードと、説明の図もたくさんある)。

この6つの原則はどれも重要なものだが、個人的には「対称性」が特に印象的だ。これは、よい文章を書くときの原則としても通じるだろう。

ベックは本書で、「意図がわかる」「読みやすい」という言い方をしょっちゅうしている。これはプログラミングの話なのだが、一般の文章を書くときの心得とまったく同じである。

ソフトウェアは、単に動けばよいというものではない。そのソースコードは、よい文章と同じように、人間に向けて、わかりやすく書く必要があるのだ。


関連エントリ:
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