C++ による BREW 開発(7)

もう少し考えてみよう。

さっきは IUNZIPASTREAM_SetStream() だけを考えたけれども、IImage にも IIMAGE_SetStream() があるし、他にもいろいろあるかもしれないし、今後増えるかもしれない。
仮に 10個の SetStream() が存在したとしよう。
そして、IMemAStream や IFiie 等の、セットされるインターフェースオブジェクトも、現在だけでかなりの量がある。
これも仮に 10個あったとする。
そうすると、これらをセットする関数の合計は、*_SetStream() を 10個用意するだけでいい。
なぜなら、全て IAStream* を引数にとって、IASTREAM_*() をするだけでいいからだ。

もしこんな方法を取らずにやっていたらどうなるだろう。
例えば IUnzipAStream の場合は、IUNZIPASTREAM_SetMemory(), IUNZIPASTREAM_SetFile(), IUNZIPASTREAM_SetSocket() ...
合計で 10個のセット関数が必要になる。
同じく IIMAGE_SetMemory(), IIMAGE_SetFile(), IIMAGE_SetSocket() ...
同じく 10個のセット関数が必要になる。
ということは、これらが１０個あるのだから、１０×１０で、合計１００個ものセット関数を作る必要が出てくるのだ。
こんなにあると容量も増えるだろうし、バグも混入しやすい。使い勝手も悪い。非常に良くない。

また、IAStream 仮想テーブルを使って、独自のストリーム関数を作ることが出来る。
例えば、メモリ上をリンクリストで繋いだ構造体を読み込むための、ILinkedListStream とかを実装することも可能なのだ。
もちろん、それらを IUNZIPASTREAM_SetStream() に渡すことも可能だ。
これは１００個のセット関数を BREW 設計者が作ったとしても、決して出来ないことだ。

つまり仮想テーブルを使う実質的な利点は、容量の削減とバグの削減、それから拡張性だ。

実質的ではない利点としては、オブジェクト指向、カプセル化、ポリモルフィズムといったものが挙げられるけれどもそれはどうでもいいので無視。