-
オブジェクト指向設計の学び方と教え方
オブジェクト指向を学ぶハードル
オブジェクト指向の説明は意味が不明
- 著者見解:言葉ではうまく説明できないし理解できない
なぜオブジェクト指向で設計すると良いのかがわからない
-
良さを実感するには…
- ある程度の規模が必要
- 何度も修正や拡張を繰り返す機会が必要
-
なかなか機会が得られない
- 最初のリリースのみ担当、以降の改善作業は他の人が担当
- 目先の個々の修正要求をこなすだけ、設計改善がない
オブジェクト指向をどうやって学ぶか
- 既存のコードを改善しながらオブジェクト指向設計を学ぶ
- やや極端なコーディング規則を使ってオブジェクト指向らしい設計を体で覚える
既存のコードを改善しながらオブジェクト指向設計を学ぶ
実際のコードで設計の違いを知る
- 変更のやりやすさ/やりにくさの体験で学ぶ
-
Fowlerのリファクタリング読め
- 【所感】2nd editionを積んでいる…
- コードスメル
重複したコード
-
1行の計算式でも、重複していると判断したら、積極的にメソッドに抽出せよ
-
【補】コンテキストが重要だと思います
- プログラマが知るべき97のこと/共有は慎重に
-
たまたま一致しているだけのこともある
- その場合、本来ないはずの依存を持ち込んでしまうことになる
-
-
ひと手間がコードを読みやすくし、変更をやりやすくする
- 【補】investment mindset (APoSD: A Philosophy of Software Design)
長いメソッド
- コメント/段落/インデントを手がかりにメソッド抽出する
-
【補】いたずらに抽出し過ぎても複雑性が上がることに注意する
-
下記のようなものはAPoSD著者の立場からすると抽出しすぎ
- 必ずペアで呼び出さなければならないメソッド
- 実装を読まないと呼び出し側コードを理解できないメソッド
- privateでもメソッドを生やすということは、開発者向けのインタフェースが複雑化するということ
-
巨大なクラス
-
パターン
- インスタンス変数が多い
- メソッドが巨大なデータクラスを受け取る
- メソッドがたくさんの引数を受け取る
リファクタリングは部分的に少しずつ
- 広範囲を一度に変更するのは危険だしその必要もない
- 修正や拡張の対象となる部分に絞ってやってみる
for each desired change, make the change easy (warning: this may be hard), then make the easy change (Kent Beck)
-
リファクタリングして変更を簡単にしてから変更する
- (変更を簡単にすること自体は難しいかも)
組み立てやすい部品に改善する
-
名前
- 抽出したてのモジュールの名前は抽出元を引きずっている
- 他のモジュールから利用するときに名前を再検討する
- 良い名前はどこに何が書いてあるか見つけやすくし、再利用性を促進する
-
クラスにロジックを追加する
- 抽出したてのクラスのロジックは当然抽出元にあったもののみ
- 他のクラスのロジックも適宜持ってくる
-
結果、巨大になってきたら再度クラスの抽出を検討する
- 改善を繰り返す
-
小さなクラスを束ねるクラスを追加する
- 【補】GoFのFacade Pattern的な気持ち
設計は少しずつ改良を続ける
- 従来の手続き型: 設計は開発の「前」
- オブジェクト指向: 開発の過程で設計を改良
オブジェクト指向らしい設計を体で覚える
古い習慣から抜け出すためのちょっと過激なコーディング規則/オブジェクト指向の考え方を理解する
- ThoughtWorksアンソロジー第5章「オブジェクト指向エクササイズ」
- 実装パターン(Kent Beck)
- オブジェクト指向入門(Bertrand Meyer)
- ドメイン駆動設計(Eric Evans)
いつか読むので略