A Philosophy of Software Design ch8. Pull Complexity Downwords

APoSDソフトウェア設計勉強メモ

出典: 


Pull Complexity Downwords

  • モジュールを開発するときは、実装ではなくインタフェースを単純化するのが大事

    • ほとんどのモジュールは、開発者よりも利用者のほうが多い

      • 【補】モジュールの開発者: 実装が単純だと嬉しい
      • 【補】モジュールの利用者: インタフェースが単純だと嬉しい
      • 【補】インタフェースを単純化することはシステム全体の複雑性を減らすことにつながる

        • 認知の負荷が下がる
  • 開発者は逆のことをしがち

    • 面倒事を他人に押し付けがち

      • 例外送出
      • コンフィグパラメータ
    • 濫用すると複雑性を増幅させてしまう

      • モジュール利用者全員がコンフィグ設定方法を学ばなければならない

Example: editor text class

  • 行指向インタフェース

    • 実装は楽

      • 内部表現が行のコレクションの場合
    • 利用側 = UIモジュールは大変

      • 「行」に対して操作することは少ない

        • 行間に挿入
        • 行をまたぐ範囲削除
      • ので、利用側に行の分割やマージ操作を強いる
  • 文字指向インタフェース

    • 実装は複雑化

      • 行の分割やマージ操作をモジュール内部で行う
    • 利用側は楽
  • 後者が良い

    • 行の分割・マージという複雑性をモジュールにカプセル化し、システム全体の複雑性を減らすことができている

Example: configuration parameters

  • 自問自答せよ:

    • 「ここで決めたよりも適切なパラメータを、利用者は決められるだろうか?」
  • コンフィグを外出しするのが適切なケース

    • 要件やワークロードに応じたチューニングが必要

      • インフラ寄りのモジュール側でベストポリシーを知ることが困難
      • モジュール利用側が熟知している
    • 例: 特定のリクエストのみ応答時間がクリティカル、等
  • そうでないケース

    • 利用者や管理者が適切なパラメータを決定するのが困難、もしくは不可能な場合
    • 例: ネットワークプロトコルの輻輳制御

      • モジュールが自動で決めるのが適している
      • 利用側が決定するのは困難

        • 適切な値を決めることができても、すぐout-of-dateになる
  • コンフィグパラメータは可能な限り避けよ

    • そもそも、モジュールは問題を完全に解決できることが理想
    • コンフィグを外出しするということは、単体では問題を完全に解決できないということ

      • システムに複雑性を持ち込んでしまう

Taking it too far

  • 複雑性を低水準側に引き下げるべきなのはこんなとき:

    • 複雑性が、その低水準モジュールの既存の機能に密に関わっている場合
    • 複雑性を引き下げることで、アプリケーションの他の部分が単純化される場合
    • 複雑性を引き下げることで、クラスのインタフェースが単純化される場合
  • やりすぎな例: Textクラスにbackspace()メソッドを生やしてしまう

    • 複雑性をTextクラスに引き下げているので良さそうに見える
    • ダメな点

      • 利用側 = UIモジュール側コードの複雑性は大して下がらない
      • backspace = UIの知識と、Textクラスの既存の機能との間に関連がない
      • UIに関する知識の漏出

Conclusion

  • モジュールを開発するときは、少し手を加えて利用側の苦労を少なくできないか探ってみよ

英語

  • punt

    • 委ねる

      • 委譲とかの文脈で使う言葉みたい