朝練メモ
- コード再利用のための{リファクタリング, デザインパターン}
- コピペ方式の問題 (災いのもと
- 人がヤる事は微妙
- 機能をつけ加えにくいプログラムへの機能追加はそれが簡単になるようにリファクタリングをナニ
- テスツの重要性
- リファクタリングする前に試験の用意
- statement メソドの試験は書きにくい
- テストは頼みの綱
- リファクタリングの前に
- 失敗するとどうなるか
- ローカルなスコープを持つ変数群に着目
- 最初のリファクタリング
- switch-case なソレを抜いた
- リファクタリングでは小さなステップでプログラムを変更していくので誤りがあっても検出が容易
- eclipse なリファクタリングのツール
- 自動でメソッド抽出?
- ヤッた事無い
- 変数名の変更
- 可読性 (コンパイラが理解できるコードは誰にでも書ける
- カタログがある模様
- ここで適用したのはメソッドの抽出 (110)
- amountFor メソドの移動で使われているカタログは_メソドの移動 (142)_との事
- Customer クラスで定義されているのに Customer クラスの情報が使われてない
- 仕様するデータを持つオブジェクトにメソドは定義されるもの
- Rental#getCharge() に名前変更
- Customer#amountFor() の中身は Rental#getCharge を戻すのみ
- 該当メソドを使っている部分をすべてのクラスにわたって「検索」する必要あり
- 古いメソド名を新しいメソドへの移譲として残す場合もあり
- thisAmount 冗長
- 問い合わせによる一時変数の置き換え (120) を適用
- 一時変数は極力取り除く
- 一時変数は不必要な引数をたくさん受け渡してしまう原因になりがち
- 長いメソドにひそむ罠
- p.69 がナニ
- 性能如何によらずとりあえず書きなおす
- 計算の責任を負うのは誰か (メソドの抽出
- リファクタリングは小さなステップで行なうのが効果的
- 修正は小規模
- こまめに試験
- 小さく変えて commit
