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

ポリシークラスってなんぞや?〜その1〜

「Modern C++ Design」を、わからないなりにとりあえずガーッと読んだ。
けど、ほんと分からん。
とりあえず、ポリシークラスの考えが、わかったようで分かってないので、1つ1つ確認してみることに。

1章 1.2 何でもやっちゃえインターフェースの失敗

クラスを設計するときに、まず最初に考えるのが「何でもやっちゃえインターフェース」。
自分が必要とする機能を、全部そのクラスだけに詰め込んでしまおうとするもの。
別な言い方をすると、巨大な全方位型インターフェース。
このようなクラスは、単純に、

  • 処理上のオーバヘッド増
  • 全体のサイズ増
  • 実行効率の低下

という理由だけでも避けるべきです。

また、不必要なまでに巨大化すると、クラスの全体像の見通しが悪くなり、コードを理解するコストも増加します。

こんだけ悪い点が出そろうと、
「いーよ、もう自分で作るから。」
と言われて、そのコードは再利用されなくなってしまいます。


これだけでも、巨大な全方位型インターフェースを選択しない理由としては十分だと思うのですが、著者は、もっとも重大な問題はその他の点にあると言います。

それは、「静的な型の安全性が欠落すること」らしいです。

著者は、
「設計によって課せられた制約のほとんどが、コンパイル時点で制約されるべきなのです。」
と言っています。

これは、すんごく、ざっくり言うと、
「実行時にエラーになるより、コンパイル時にエラーになってくれた方がありがたくねー?」
ってことだと思います。

例えば、
ある関数の設計が、「長さの決まった配列しか渡せない。」となっていた場合、コンパイル時にポインタを渡そうとしていたら、コンパイルエラーが出てくれた方がありがたい。
っのような感じかなと。(良い例が思いつかなかった…)

というわけで、実行時にエラーになるようなものは、コンパイル時にエラーになってくれた方がありがたいのですが、巨大な全方位インターフェースだと、これを実現するのが難しいのだそうです。
これを著者は、「シンタックス上は有効なものとセマンティックス上は有効なものの格差が広がってゆく。」と表現しています。




うむうむ。なんとなくわかったような…。


...続く。