【開発哲学４_11】〜『リファクタリング 既存のコードを安全に改善する』〜第11章 継承の取り扱い〜
時間があったので、次いでに〜🕺
感想
継承（＝ポリモーフィズム）の取り扱い
なんて仰々しい章題だからよほど小難しい話かと思ったわ！
さらっと読んで、要は
ルーチンやクラスの意味と役割を理解して、
重複を避けながら、
スーパクラスやインターフェースなんかに
まとめれるものはまとめて、
違うものはサブクラスとかルーチンに小分けにしようね
ってだけの話。
Javaに限らず
全てのオブジェクト言語で常に意識される基本中の基本かなと。
まあ、基本を理解してない人で、目先で動かすことを優先してると、やってしまいがちだけど。
そんな人ほど、「コードの整理なんかしなくても」とリファクタリングを理解してなかったりするのよね〜〜〜〜
詳細
見出しとしては、
フィールドの引き上げ
メソッドの引き上げ
コンストラクタ本体の引き上げ
メソッドの引き下げ
フィールドの引き下げ
サブクラスの抽出
スーパークラスの抽出
インターフェースの抽出
階層の平坦化
Template Methodの形成
委譲による継承の置き換え
継承による委譲の置き換え
てな感じ。
以外は感想で書いたとおり。
グローバル変数とかになりそうな気がするから、それはそれでコンストラクションの鉄則には反する気もするけどね。
ここまでで
細かいリファクタリングの手法は終わりっぽいけど、
リファクタリングで一番肝心なのは、どんな方法を使っても何かしらコードを改修したなら、ロジックが完璧とか思い込まずに、
コード改修後、すぐに
ちゃんと期待どおりの結果になっているか
コンパイルしてテストする
リファクタリング前にバックアップを取っておく
ことだね〜〜〜
バグがないかの確認を統合テストでとか、恐ろしすぎる〜〜〜。
ウォータフォール型統合だとそうなることが多いけど。
最近は、アジャイルでイテレーションを駆使しながら、テスト駆動開発が主流だろうからそんなことはないか。
バックアップ取らなくてもバージョン管理もしてるだろうし。
まとめ
リファクタリングは新しいバグの原因と紙一重
💃重複と意味のないクラス配置や委譲はバグの原因。
バグの原因の8割は汚い整理されていないコード
＝デザインが良くないファッションと同じ🕺