実装パターン

実装パターン

ケント・ベックの本は平易な語り口や言い回し、本から滲み出る考え方も含めて好きだったりする。
「実装パターン」は

"コードは人のためによる、人のためのものだ"

とし、プログラムの価値を

• コミュニケーション
  • 他者に意図を伝えるクラス名・メソッド名・コーディング
• シンプル
  • より素早く理解できるコード
• 柔軟性

であるとしている。
上の価値をベースにした6つの原則を土台に、クラス設計やコーディング上での小さな判断における基準を示してある。
「リファクタリング」や「テスト駆動開発入門」の例で時折でてくる"設計上の判断"、そういうデザインパターンにまで落ちない部分について"あの例はこういう基準のもとで判断されていたのか"と得心いく気持ちだった。
際立って珍しい概念が提示された印象はなかったけれど、細かな実装上の判断や後から見直すときのチェックポイントとして、意識するのにいい。

フレームワークの拡張

著者自身がJUnitの開発者でEclipseとも浅からぬ関係があるという身の上、フレームワークにまつわるバージョンアップと互換性への配慮についても実感が籠もっていて一読の価値あるかなと思う。
とはいえ、「公開する情報をできるだけ少なく」や「非互換のアップデートの場合は非推奨からはじめたり、バージョンアップツールを用意する」といった点に関しては結構ベタな話だなとは思った。
「ユーザにコードを変えてもらうことに一番コストがかかる」という部分は重い発言だと思う。

OOPの解釈

「OOPは状態への対処戦略」という言い回しは、結構気に入った。

つぶやき

遠い目をして書くけれど、柔軟性を確保することができるファクトリメソッド、最初は物珍しさで使ってみたくなるけれど、それはシンプルさとのトレードオフとして存在するのであって万能薬じゃないってことにこのとき気づいていない、みたいな。たいていの場合は普通にコンストラクタでインスタンス生成するほうがうまくいくし読みやすいし必要十分だし？みたいな。わざわざ複雑性を持ち込んだコスト(=ファクトリメソッド)をペイする場面がいつまでも来ませんよね？みたいな…そういった「柔軟性はシンプルさを犠牲にした上に成り立つ」ってのが何度も本に出てきて、パターン使ってみたい魔だった昔を思い出したりした。(今、その病気が治っているかどうかは、分からない…)

なんだかんだで、なるべく普通に書くことがいいのね…と言ってしまうと、「幸せは実は身近なところに」と言っているように聞こえてなんともいえない気分になる。