読者です 読者をやめる 読者になる 読者になる

$shibayu36->blog;

株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。

「オブジェクト指向入門 第3章モジュール性」メモ

tech

以前途中まで読んで読みきれなかったのでオブジェクト指向入門をまた読み始めることにした。また、理解を深めるために章ごとに面白いことがあったらまとめておくことにした。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

今回は第3章のモジュール性というところを読んだ。この章は「モジュール性の高い」手法のためには、具体的にはどのような性質が必要なのかということについて書かれている。基準 -> 規則 -> 原則とブレークダウンしながら必要条件を学んでいくことができる。それぞれの基準や規則、原則を、特定の言語(例: Perl, Scala, Go, JavaScriptなど)が満たしているかどうかについて考えてみると面白かった。

あとはそれぞれの基準とかのメモを置いておく

5つの基準 50ページから

「モジュール性がある」と呼ぶ価値のある設計手法は、5つの基本的な必要条件を満たす必要がある。

  • 分解しやすさ
    • ソフトウェアの構造を、単純な構造を組み合わせた形に設計してあること
  • 組み合わせやすさ
    • モジュールが独立していて、いろんなパターンで組み合わせられる
  • モジュールの分かりやすさ
    • そのモジュールもしくは少ないモジュールの知識だけで、そのモジュールを理解できる
    • つまりクラスAを知るためにはそれだけ見れば理解できると良く、そうでなくてクラスAを知るためだけにクラスBの内部実装まで知っていないといけないならだめ
  • モジュールの連続性
    • 仕様に変更があっても、1つか少数のモジュールの変更しか行われない
    • DRYっぽい
  • モジュールの保護性
    • 実行時にエラーが起こっても、モジュール内もしくは少数のモジュールにしか影響が広がらない

5つの規則 58ページから

基準から、モジュール性を保証するために守らなければならない5つの規則が導かれる。

  • 直接的な写像
    • ある問題領域を記述する良いモデルがある場合、モジュールとモデルとして表現される構造のマッピングが明快であること
  • 少ないインターフェース
    • 全てのモジュールができる限り少ない数のモジュールとの通信で済むように
  • 小さいインターフェース
    • 2つのモジュールが通信する場合、そこで交信される情報はできるだけ少なくする
  • 明示的なインターフェース
    • 暗黙的に同じデータを共有してそれに依存するなどをせず、二つのモジュールの通信は公に行う
  • 情報隠蔽
    • モジュールは必要な情報だけ公開し、あとは非公開とするべき

5つの原則 67ページから

規則と、間接的には基準から、ソフトウェア構築の5つの原則が導かれる。

  • 言語としてのモジュール単位
    • モジュールは使用される言語の構文単位に対応していなければならない
  • 自己文書化
    • モジュールについての全ての情報をそのモジュールの一部として作るべき
  • 統一形式アクセス
    • フィールドでもメソッドでも同じような形式でアクセスできるように
  • 開放/閉鎖の原則
    • モジュールは拡張可能で、かつ変更せずに追加のみで拡張できる
    • この原則は有名なので、ググったほうがわかりやすい
  • 単一責任選択
    • システムが選択肢を提供する時、そのシステムの1つのモジュールだけがその選択肢のすべてを把握すべき
    • enumで列挙されている選択しはは一つのモジュールが責任取るべきみたいな