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サーバ実装
- クラス内での情報隠蔽
- 行き過ぎた情報隠蔽
- モジュールの用途によって異なるパラメータが必要な場合は、その情報がモジュールの外で必要とされると解釈する
- モジュール外部で必要な情報の量を最小限にする