ここでは「ポータブルなアプリケーションを書く労力が経済的に正当化できる」という前提のもとで、有用なテクニックを紹介する。
インタプリタ言語は、コンパイル言語に比べてポータビリティに優れている。インタプリタが、基盤となるOSとの間を切り離すレイヤーとなるからだ。 もちろん万能ではないが、一般論として、ポータブルなシステムを構築しようとするならインタプリタ言語を使うほうが理にかなっている。
もしコンパイル言語を使うなら、ポータビリティを確保するためのイディオムを開発チームに教え込む必要がある。 たとえばC/C++なら、ターゲットプラットフォームごとに適切なファイルを選んだり、条件付インクルードを使ったりなど。 難しいのはわかるけど、できないことはない。がんばれ。
ここでいう永続ストレージとは、ハードディスクなどのメディアにデータを格納したりそこからデータを取得したりする手段のこと。 シンプルなデータならXMLを使えばいいし、複雑な構造化データならRDBを使えばいい。
システムの中でいちばんポータブルであるべきなのは、ビジネスロジック(詳しくは第8章で)。 もしビジネスロジックのコードがポータブルになっていなければ、もう一度見直してみよう。 きっと、開発スタッフの実装があまりうまくないはず。
バックエンド側が最大のポータビリティを持っていて、ユーザー側に向かえば向かうほどそれが低下する。 その最たるものがUI。色・フォント・解像度など、デバイスによって大きく異なる。 それはしょうがないものなので、バックエンド側のポータビリティに力を入れるのが現実的だ。
サブシステム間の相互運用性の問題って大変。たけど、そういったことは頭のいい人たちがすでに解決してくれてるので、XMLとかSOAPとか使っておけばだいじょうぶ。やったね!
ハイパフォーマンスが求められる場面なら、それ以外のソリューションも考えたくなるかもしれない。でも、よっぽどのことがない限りはやめといたほうがいいよ。遅いとはいえ、XMLはかなり柔軟なソリューションなのだから。
データベースを例に考えると、大手ベンダーは口をそろえて「ANSI SQLに準拠してます!」と言うけれど、彼らはみんな、自社独自の方言を用意している。 Oracleで階層化データの扱う機能とかSQL Server 2000でのXML操作コマンド群とか、めちゃめちゃ便利。 ポータビリティを保つっていうのは、決して「最大公約数の機能でなんとかする」ってことじゃない。ターキテクチャを工夫して、プラットフォーム固有のすてきな機能も使えるようにしよう。