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