TL;DR
- 避けられない複雑さがモジュールの機能に関わるなら、利用者に任せずモジュールの内部で扱うほうがよい。
- ただし、複雑さを下に引き下げるのは、既存の機能と密接に関係し、他の部分やインタフェースがシンプルになる場合に限る。
内容
複雑さを下に引き下げる
避けられない複雑さを、モジュールの利用者に任せるか、モジュールの内部で扱うか。その複雑さがモジュールの提供する機能に関わるなら、内部で扱うほうがよい。これを「複雑さを下に引き下げる（pull complexity downwards）」という。モジュールの利用者は開発者より多いので、開発者は利用者ができるだけ楽になるよう最善を尽くすべきである。モジュールにとっては、シンプルな実装よりシンプルなインタフェースのほうが重要である。
次のようなインタフェースは利用者に負担をかけ、複雑さを増やす。
1 つは、例外を投げて呼び出し元に処理させるインタフェースである。すべての呼び出し元が例外に対処しなければならない。
もう 1 つは、振る舞いを制御する設定パラメータを受け取るインタフェースである。利用者全員が、どんな値が適切かを学ばなければならない。設定パラメータを採用するなら、「利用者や上位のモジュールは、ここで自分が決められる値よりも良い値を選べるか」を自問する。また、デフォルト値を用意し、まれなケースでだけ値を指定すればよいようにすることも大切である。
やりすぎに注意
複雑さの引き下げはやりすぎることが多いので、慎重に行う。極端な例はアプリケーション全体を 1 つのクラスにまとめることだが、これには意味がない。複雑さを引き下げるのが理にかなうのは、次の場合である。
- 引き下げる複雑さが、クラスの既存の機能と密接に関係している
- 引き下げることで、アプリケーションの他の部分がシンプルになる
- 引き下げることで、クラスのインタフェースがシンプルになる
モジュールを開発するときは、利用者や上位のモジュールが楽になるように、自分が少し苦労を引き受けるのがよい。