勉強日記

チラ裏

現場で役立つシステム設計の原則 ch10

gihyo.jp


オブジェクト指向設計の学び方と教え方

オブジェクト指向を学ぶハードル

オブジェクト指向の説明は意味が不明

  • 著者見解:言葉ではうまく説明できないし理解できない

なぜオブジェクト指向で設計すると良いのかがわからない

  • 良さを実感するには...
    • ある程度の規模が必要
    • 何度も修正や拡張を繰り返す機会が必要
  • なかなか機会が得られない
    • 最初のリリースのみ担当、以降の改善作業は他の人が担当
    • 目先の個々の修正要求をこなすだけ、設計改善がない

オブジェクト指向をどうやって学ぶか

既存のコードを改善しながらオブジェクト指向設計を学ぶ

実際のコードで設計の違いを知る

  • 変更のやりやすさ/やりにくさの体験で学ぶ
  • Fowlerのリファクタリング読め
    • 【所感】2nd editionを積んでいる…
    • コードスメル

重複したコード

  • 1行の計算式でも、重複していると判断したら、積極的にメソッドに抽出せよ
  • ひと手間がコードを読みやすくし、変更をやりやすくする

長いメソッド

  • コメント/段落/インデントを手がかりにメソッド抽出する
  • 【補】いたずらに抽出し過ぎても複雑性が上がることに注意する
    • 下記のようなものはAPoSD著者の立場からすると抽出しすぎ
      • 必ずペアで呼び出さなければならないメソッド
      • 実装を読まないと呼び出し側コードを理解できないメソッド
    • privateでもメソッドを生やすということは、開発者向けのインタフェースが複雑化するということ

巨大なクラス

  • パターン
    • インスタンス変数が多い
    • メソッドが巨大なデータクラスを受け取る
    • メソッドがたくさんの引数を受け取る

状態遷移図

リファクタリングは部分的に少しずつ

  • 広範囲を一度に変更するのは危険だしその必要もない
  • 修正や拡張の対象となる部分に絞ってやってみる

【補】Kent Beckの至言

for each desired change, make the change easy (warning: this may be hard), then make the easy change (Kent Beck)

  • リファクタリングして変更を簡単にしてから変更する
    • (変更を簡単にすること自体は難しいかも)

組み立てやすい部品に改善する

  • 名前
    • 抽出したてのモジュールの名前は抽出元を引きずっている
    • 他のモジュールから利用するときに名前を再検討する
    • 良い名前はどこに何が書いてあるか見つけやすくし、再利用性を促進する
  • クラスにロジックを追加する
    • 抽出したてのクラスのロジックは当然抽出元にあったもののみ
    • 他のクラスのロジックも適宜持ってくる
    • 結果、巨大になってきたら再度クラスの抽出を検討する
      • 改善を繰り返す
  • 小さなクラスを束ねるクラスを追加する
    • 【補】GoFのFacade Pattern的な気持ち

設計は少しずつ改良を続ける

オブジェクト指向らしい設計を体で覚える

古い習慣から抜け出すためのちょっと過激なコーディング規則/オブジェクト指向の考え方を理解する

いつか読むので略