A Philosophy of Software Designの9章要約
本内容は「A Philosophy of Software Design」の9章を要約する記事です。
過去記事
- A Philosophy of Software Designの3章要約 - なになれ
- A Philosophy of Software Designの5章要約 - なになれ
- A Philosophy of Software Designの7章要約 - なになれ
8章の紹介
他担当の方が要約した8章の内容を引用します。
- 8章 複雑さを下へ下へと引き下げる
- より深いクラスを作るときに複雑な部分を発見した場合の対応について
- 新しいモジュールを開発しているときに、避けられない複雑な部分を発見した場合、その複雑さがモジュールによって提供される機能に関連しているのであればモジュールの内部でその複雑さを処理すべき
- モジュールにとって重要なのは、シンプルな実装よりもシンプルなインターフェイスであること
- 最も簡単なのは、例外を投げて呼び出し元に処理を任せること
- クラスが例外を投げると、そのクラスのすべての呼び出し元がその例外に対処しなければならなくなる
- どのようなポリシーを実装すればよいかわからない場合は、ポリシーを制御するための設定パラメータをいくつか定義し、それらに最適な値を見つけ出すことをシステム管理者に任せること
- クラスが設定パラメータをエクスポートする場合、すべてのインストレーションのすべてのシステム管理者は、それらを設定する方法を学ばなければならない
- これらのようなアプローチは、短期的には生活を楽にしますが、複雑さを増幅させ、一人ではなく、多くの人が問題に対処しなければならなくなる
- 前章の学生の実装
- 設定パラメータは、複雑さを軽減するのではなく、上向きにする例
- 構成パラメータは、重要な問題への対処を避け、他の誰かに転嫁するための簡単な口実にもなります
- 設定パラメータをエクスポートする前に、自問自答してみてください。“ユーザー（または上位モジュール）は、ここで決定できる値よりも良い値を決定できるだろうか？”
- 設定パラメータを作成する場合、合理的なデフォルト値を提供できるかどうかを確認し、ユーザーは例外的な状況下でのみ値を提供する必要があるようにします
- やりすぎになりやすいアイデアとされ複雑さを下方に引っ張るときは慎重を期すこと。
- 以下のケースでは複雑さの軽減は最も意味のあることとされる
- (a)クラスの既存の機能と密接に関係している場合
- (b)複雑さを軽減することで、アプリケーションの他の部分も簡素化できる場合
- (c)複雑さを軽減することでクラスのインターフェースが簡素化できる場合
- 目標は、システム全体の複雑さを最小化することであること
9章要約
- 9章 一緒がいいか、別々がいいか
- 概要
- どのような場合にコードの断片をまとめることが意味を持ち、どのような場合にそれらを分離することが意味を持つかを示す
- 情報が共有されている場合はまとめる
- インターフェースを簡略化できるのであればまとめる
- HTTPサーバーを実装した例を再度引用
- 2つの処理が別モジュールで実装されている場合、リクエストの情報を渡す必要があるため、インタフェースがその分必要になっていたが、一つのモジュールにすることでそのインタフェースは不要になる
- 重複を避けるためにまとめる
- 汎用コードと特殊目的コードの分離
- 6章の話
- 特殊用途のコードを上位層に引き込み、下位層は一般用途のままにする
- メソッドの分割と結合
- 長さだけでメソッドを分割する正当な理由となることはほとんどない
- メソッドを設計する際に最も重要な目標は、クリーンでシンプルな抽象化を提供すること。各メソッドは1つのことを完全に行う必要がある
- それぞれのメソッドを独立して理解することが可能であるべき。もし、あるメソッドの実装を理解するために、別のメソッドの実装も理解しなければならないなら、それは赤信号である
- まとめ
- モジュールの分割や結合は、複雑さに基づいて決定する必要がある。最も優れた情報隠蔽、最も少ない依存性、最も深いインタフェースを実現する構造を選ぶ
感想
- Deep Moduleを作るためのこれまでのまとめ的な内容だった
- 汎用コードと特殊目的コードの分離の箇所について具体的なイメージがつかめていない
