「パターン指向リファクタリング」読了!
読みました。前回のレガシーコード本の読了から、大体1ヶ月半くらい。通勤中にしか読んでないけど、他に読みたい本もいっぱいあることですしもうちょっと早く読みたいものです。
パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法
- 作者: ジョシュア・ケリーエブスキー,小黒直樹,村上歴,高橋一成,越智典子
- 出版社/メーカー: 日経BP社
- 発売日: 2005/08/04
- メディア: 単行本
- 購入: 11人 クリック: 261回
- この商品を含むブログ (123件) を見る
第1章 本書を執筆した理由
進化的設計
「進化の結果を調べるよりも、そういった設計へ進化した理由を調べる」。デザインパターンなどはまさにそうだと思うけど、最後の完成形だけ見ても実際に適用することはできないんですよね。もちろん、完成形を見て美しいと思うことはありますが。それより、どういう経路でその設計/実装を採用するにあたったか?を心に刻んでおきたい。
第2章 リファクタリング
設計の負債
「設計の負債」とか「技術的な負債」とかはよく耳にするメタファですね。これが真に効果的なのは、技術的なことがあまり分からない経営陣*1を相手に話す状況でのこと。まぁ、このメタファだけでエンジニアの言わんとすることが全てが理解できるとは思いませんが、最初の取り掛かりにはなるでしょう。
第6章 生成
Factoryによる生成処理の置き換え
「Factory」には色々意味がある。一番広く使える「一つ以上のCreationメソッドを実装しているクラス」が間違いなさそう。あとは、文脈から判断して。
第7章 単純化
Stateによる状態変化のための条件判断の置き換え
この図が本書の例ですが、これくらいは複雑でないとあまりStateパターンの意味がない。単純なStateしかないのに無理やりStateパターンを導入しても、抽象化しすぎてわかりにくくなるだけ。
ちなみに、何で状態が複雑な場合にStateパターンを使わないと複雑になるかというと、「関係のないロジックの中にはたいてい、現在の状態の検証や、関係のない状態への遷移ロジックが含まれる。」からだそうです。Stateパターンを使うと、現在の状態の検証などをクラス構造で表現できるから。逆に言うと、遷移ロジックが十分に簡単な場合にはStateパターンを使うまでもないということですね。
Commandによる条件つきディスパッチャの置き換え
「Commandパターンは、実装しやすく、用途が広く、非常に効果的である」とのこと。サーバサイドでは、たいていやられていると。
第8章 汎用化
Template Methodの形成
「リファクタリングにはドメインの知識が役に立つ」。自分は…前職で携わっていた卸売業+簿記周り?
次に読んでいるのはJUnit in Action。ちょっと古い本だから現状に即していないことはあるだろうけど、それでもPOJOでない環境をいかにうまくユニットテスト環境に落とし込むか?などのアイデアは触れておいて損はないはず。多分…
- 作者: ビンセントマソル,テッドハスティード,Vincent Massol,Ted Husted,クイープ
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2004/05
- メディア: 単行本
- クリック: 53回
- この商品を含むブログ (41件) を見る
ちなみに、今回ブログにはろうと検索して気づいたけど、洋書だと第2版が出てるみたいですね。これも読んでみたいかな。
- 作者: Petar Tahchiev,Felipe Leme,Vincent Massol,Gary Gregory
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2010/07/23
- メディア: ペーパーバック
- クリック: 16回
- この商品を含むブログ (12件) を見る
*1:そもそも、そういう経営陣は大丈夫なのか?という根本的な問題もありますが…