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

勉強メモ現場で役立つシステム設計の原則

出典: 

-

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

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

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

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

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

  • 良さを実感するには…

    • ある程度の規模が必要
    • 何度も修正や拡張を繰り返す機会が必要
  • なかなか機会が得られない

    • 最初のリリースのみ担当、以降の改善作業は他の人が担当
    • 目先の個々の修正要求をこなすだけ、設計改善がない

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

  • 既存のコードを改善しながらオブジェクト指向設計を学ぶ
  • やや極端なコーディング規則を使ってオブジェクト指向らしい設計を体で覚える

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

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

  • 変更のやりやすさ/やりにくさの体験で学ぶ
  • Fowlerのリファクタリング読め

    • 【所感】2nd editionを積んでいる…
    • コードスメル

重複したコード

  • 1行の計算式でも、重複していると判断したら、積極的にメソッドに抽出せよ

  • ひと手間がコードを読みやすくし、変更をやりやすくする

    • 【補】investment mindset (APoSD: A Philosophy of Software Design)

長いメソッド

  • コメント/段落/インデントを手がかりにメソッド抽出する
  • 【補】いたずらに抽出し過ぎても複雑性が上がることに注意する

    • 下記のようなものは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的な気持ち

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

  • 従来の手続き型: 設計は開発の「前」
  • オブジェクト指向: 開発の過程で設計を改良

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

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

  • ThoughtWorksアンソロジー第5章「オブジェクト指向エクササイズ」
  • 実装パターン(Kent Beck)
  • オブジェクト指向入門(Bertrand Meyer)
  • ドメイン駆動設計(Eric Evans)

いつか読むので略