なになれ

IT系のことを記録していきます

A Philosophy of Software Designの5章要約

本内容は「A Philosophy of Software Design」の5章を要約する記事です。

過去記事

4章の紹介

他担当の方が要約した4章の内容を引用します。

  • 4章 モジュールは深くあるべき
  • moduleの増加により相互依存が生まれる、これによりアプリケーションの複雑さが増加する
  • 依存関係の理解がインターフェイスと実装により行うことができ、この設計が重要である
  • 各モジュールはインターフェースという形で実装を抽象化し提供する
    • 抽象化により複雑な実装をシンプルに理解できる事が可能
    • 抽象化の過程で抽象化の失敗や、重要な情報を省くなど起こることもある
  • 良いmoduleはDeep module, 逆に悪いmoduleはshallow module
  • shallow moduleは設計時のred flagとされる
  • module設計において、小さい単位が優れているとされがちだが誤っている
    • 多数のmodule(機能は単純でも)とその依存関係により複雑性が高まる
  • class設計においては、小さい単位のclass設計は優れているとされがち

5章要約

  • 5章 情報隠蔽(と情報漏えい)
  • 概要
    • Deep Moduleを作成するためのテクニックを紹介する章
    • 情報隠蔽がキーワード
  • 情報隠蔽
    • 実装の詳細はモジュール内に閉じる
      • 詳細の例
        • B-treeに情報を格納する方法とその効率的なアクセス方法
        • JSONドキュメントのパース方法
    • メリット
      • モジュールへのインタフェースを簡略化する
      • 変更を容易にする
  • アンチパターン1:情報漏洩
    • 設計上の決定が複数のモジュールに反映されている
      • 複数のモジュールのインタフェースに影響がある
      • 複数のモジュール内の実装に影響がある
    • 解決策
      • 簡単なインタフェースを持つ1つのクラスにする
  • アンチパターン2:時間的分解
    • クラス構造が時間順序で分かれている
      • 例:ファイルを読むクラス、変更を行うクラス、書き出すクラス
    • 解決策
      • モジュールを設計するときは、タスクの発生順序ではなく、各タスクを実行するために必要な知識に注目する
  • 例:学生によるHTTPサーバ実装
    • 多すぎるクラス
      • 悪い例
        • リクエストを読むクラスとリクエストを解析するクラスを用意した
        • クラスを少し大きくすることで情報隠蔽性を向上させることができる
    • HTTPパラメータの処理
      • 良い例
        • クエリパラメータとBodyのパラメータを同一に扱う
        • パラメータのデコード処理をクラス内で隠蔽する
      • 悪い例
        • パラメータの詳細が隠れていない
          • 全てのパラメータの参照となるMapを扱う
          • データ型(文字列、整数など)ごとにパラメータ取得用のメソッドを用意するのが良い
    • HTTPレスポンスのデフォルト
      • 悪い例
        • HTTPプロトコルバージョンのデフォルト指定がない
        • デフォルト値はよくあるケースを単純化するので良い設計
  • クラス内での情報隠蔽
  • 行き過ぎた情報隠蔽
    • モジュールの用途によって異なるパラメータが必要な場合は、その情報がモジュールの外で必要とされると解釈する
    • モジュール外部で必要な情報の量を最小限にする

感想

  • 時間的分解は構造化プログラミングに慣れ過ぎてしまうとやりがちかもしれない。オブジェクト指向プログラミングはやっぱり良いんだなぁ
  • Mapにして全ての情報をそのまま扱うパラメータにしがちなので気を付けたい。適切に情報隠蔽するように心がけたい