Pull Complexity Downwords

Example: editor text class

自問自答せよ:
- 「ここで決めたよりも適切なパラメータを、利用者は決められるだろうか？」
コンフィグを外出しするのが適切なケース
- 要件やワークロードに応じたチューニングが必要
  - インフラ寄りのモジュール側でベストポリシーを知ることが困難
  - モジュール利用側が熟知している
- 例: 特定のリクエストのみ応答時間がクリティカル、等
そうでないケース
- 利用者や管理者が適切なパラメータを決定するのが困難、もしくは不可能な場合
- 例: ネットワークプロトコルの輻輳制御
  - モジュールが自動で決めるのが適している
  - 利用側が決定するのは困難
    - 適切な値を決めることができても、すぐout-of-dateになる
コンフィグパラメータは可能な限り避けよ
- そもそも、モジュールは問題を完全に解決できることが理想
- コンフィグを外出しするということは、単体では問題を完全に解決できないということ
  - システムに複雑性を持ち込んでしまう

複雑性を低水準側に引き下げるべきなのはこんなとき:
- 複雑性が、その低水準モジュールの既存の機能に密に関わっている場合
- 複雑性を引き下げることで、アプリケーションの他の部分が単純化される場合
- 複雑性を引き下げることで、クラスのインタフェースが単純化される場合
やりすぎな例: Textクラスにbackspace()メソッドを生やしてしまう
- 複雑性をTextクラスに引き下げているので良さそうに見える
- ダメな点
  - 利用側 = UIモジュール側コードの複雑性は大して下がらない
  - backspace = UIの知識と、Textクラスの既存の機能との間に関連がない
  - UIに関する知識の漏出