オブジェクト指向的ファイル操作とは？
〜 ストリームで扱う抽象的で安全なファイル入出力 〜

　前回「Symbian OSのファイル操作を悩まずに使いこなす」では基本機能シリーズの最終回と宣言しつつ、ファイル回りの低水準のAPIについてアレコレ説明したところで紙幅が尽きてしまいました。

　というわけで、今回はファイル関連の残り半分、ファイルを使って情報の永続化を行うためにSymbian OSが用意している「ストリーム（とストア）」というフレームワークについて説明を行います（注1）。

前回解説されなかった“謎”のコード

　では、前回の最後の部分からリプレイです。Carbide.c++が生成したスケルトンコードでは、RFileからの読み込み結果をHBufCのインスタンスに直接受けるのではなく、いったんRFileReadStreamというクラスのインスタンスを構築し、それ経由で値の設定を行っています（図1）。

図1　ECommand2ハンドラの未解説部分（前回の図5）

　なぜ、RFileのメソッドである

などを使ってファイルの読み書きを行わないのでしょうか？ ここにポイントがあります。

　（A）の引数を見てみると、aDesは「バイナリディスクリプタ」です（コラム参照）。考えてみれば当たり前ですが、入出力されるデータが何を意味しているのかはファイルを使う側だけが知っていることです。だから低レベルのファイル操作APIでは、どのようなデータでも受けられる（だけど、意味については関知しない）バイナリ形式でインターフェイスを取ることになります。

　とはいえ、プログラム中で扱うデータの形式とファイルに読み書きするときのデータの形式にギャップがあるのは、ファイルを使うプログラムを書く方からすると面白くアリマセン。やりたいことは32bit型の整数や文字列（注2）などをファイルに適切に保存して、使いたいときに持ってくることなのであって、バイナリ形式に変換し、保存するときのアレコレをいちいち考慮したいわけではないからです。そこで、ギャップを埋めるものが必要になってきます。そのために用意されている仕掛けが、ストリームです。

ストリーム

　Javaなどがそうであるように、最近の開発環境（言語＋フレームワーク）では、入出力の源泉となるクラス（以後、ソースと記します）と、入出力のインターフェイスを行うクラス（ストリーム）を分離する構成を取るのが一般的です。ストリームはその名前から明らかなように、データを順次読み込み、または書き出しする操作を抽象化するためのもので、“読み書きの方向”と“現在位置”という概念を持っています（任意の位置にシークできるかどうかはソース次第です）。また、読み込みストリーム、書き出しストリームは異なるクラスで提供されることがもっぱらです。

　もちろん、Symbian OSでも図1にあるとおりストリームが提供されているわけですが、それは以下のメリットが期待できるからです。

A）データを読み書きする利用者側のコードからソースの実装を分離し、差異を隠ぺいできる
B）実行中のプログラムが扱う形式（内部形式）と保存するときの形式（外部形式）に変換を行うためのレイヤを設定できる

　一般にストリームというとA）の性質（利点）が強調されがちですが、内部形式←→外部形式変換がサポートされることも同様に重要です。ということで、これらの性質にフォーカスして、Symbian OSのストリームの概観を説明していきます。ただし、Symbian OSにおいても、ストリームは読み込み、書き出しで異なるクラス定義を持っており、両方同時に追いかけていくと混乱を来す恐れもあるので、まずは読み込みストリームからはじめることにします。

RReadStream

　では、図1で出てきたRFileReadStreamをDocBrowser（もしくは、s32file.h）で確認してみましょう。RReadStreamというクラスが基底クラスであることが分かります。これこそが読み込み側ストリームの大本です。先ほどのA）の性質を満たすよう、RReadStream（s32strm.h在中）は以下の派生クラスを持ちます（表1）。

　しかし、HBufCのファクトリメソッドであるHBufC::NewLCのシグネチャは以下のとおりです。

　つまり、HBufC::NewLC自体は、RReadStreamの派生クラスを経由することで、ファイルに限らず表1にあるソースを用いてTDesCのインスタンスを構築できるわけです。ソースをファイルからDBに変えたとしても、ストリームを差し替えればほかのプログラムに手を入れる必要がないのですから、これは確かにアリガタイことです。これこそ、A）が提供しようとしていた利便性です。

　対して、B）の性質は派生クラスを通じてではなく、RReadStreamのメソッド定義自体によって保証されます。RReadStreamの定義をのぞいてみましょう（図2）。

図2　RReadStreamのメソッド抜粋

　引数が異なるReadL()メソッド（オーバーロードですね）と、Read＜戻り値型名＞L()の形式を持つメソッドが多数提供されています。個数はありますが、これらのメソッドは同じ定義の機能を提供します。

• 引数または戻り値で示される型の値が、ストリームの現在位置から読み出せると信じて読み込みを行う

　この機能の意味するところは、「ストリーム中にどのような形式（外部形式）で保存されているかを隠ぺいしつつ、実行中のプログラムが扱う形式（内部形式）で取り出すことを保証する」です。読めると信じた型で値を受け取るメソッドを発行すればデータが取り出せるわけですから（注4）、これはまさにB）の性質です。

　なお、オーバーロードと、型名込みの命名規則（Read＜戻り値型名＞L()の形式）を使って、Readメソッドを大量に定義しているのは、データを読み出す型ごとにメソッドを分離して、タイプセーフにするためです。古典的なCのスタイルでAPIを定義すると、多分以下のようになると思います（図3）。

図3　Cスタイルのインターフェイス（もちろんAntiPattern）

　上記のような場合、void* aStoreをTReadType aTypeの値に合わせてキャストして参照、書き込みすることになりますが、このスタイル、まったくもってタイプセーフではアリマセン。CからC++への引っ越しが完了した開発者であれば、図2のインターフェイス定義の方が、図3のスタイルよりベターであると自然に思えるはずです。