はじめに
ソフトウェアシステムは決して完璧なものではありません。開発者はほぼ例外なく、システム品質と要求とのバランスを取る必要に迫られます。ソフトウェアはリリースしなければ話になりません。そのため、開発者は自分が最も適切だと考えるデザインで作業を進めていかなくてはいけません。
また、開発者はソフトウェアがリリース後、実際にどのように使われるかもよく知っています。この効果は、公開されたプログラミングインターフェース（つまりAPI）を必要とするシステムを構築するとき、顕著に現れます。APIの主な目的は、さまざまな人がソフトウェア製品を再利用できるようにすることにあります。
もし、ある決まった人たちだけしかソフトウェアモジュールを利用しないのであれば、開発者は「公開API」についてあれこれ話題にしたりしませんし、ソフトウェアをできるだけきちんと設計したり、将来性を考えたりするのに多くの時間を費やすことはないでしょう。結局は自分達の手の届く範囲内にあり、それゆえ変更も簡単です。しかし、APIがいったん外部に公開され、他の開発者らが利用するようになれば、簡単に手直しするわけにはいきません。
このような設計上の失敗の具体例として、Javaの日付やカレンダーを扱うクラスを挙げることができます。Java 1.0で導入されたjava.util.Dateクラスのゲッターメソッド（getMonth、getYearなど）は、バージョン1.1以降では非推奨にされてしまいました。たしかSunが各国対応の日付ソリューションについて説明したところでは、Dateクラスはそうではなかったという話でした。
Dateクラスは既に多用されていたため、Sunはアプリケーションを損なわずにDateクラスを変更することはできませんでした。そこでSunは問題解決のために、各国対応アプリケーション用サポートを追加した、重たいCalendarクラスを導入しました。この設計は、ひいき目に見ても難解なものでした。私の知る限りでは、かなり多くの開発チームが、もっと単純なソリューションを作るためにJavaの日付関連のライブラリクラスの周囲にラッパークラスを作っています。
このようなチームが作っているラッパークラスが、いわゆるファサード（Facade）です。ソフトウェアデザインの用語で、ファサードとは複雑なAPIをシンプルにするためのインターフェースのことです。ファサードを導入すると、システム内部の概念を単純化して理解することができ、保守費用も抑えることができます。また、APIをファサードの向こう側に隠蔽することで、柔軟性も向上します。
Java 2 SE 1.5で導入されたProcessBuilder APIも、ファサードの導入を考えるきっかけになりやすいソリューションです。ProcessBuilderクラスは、Javaクラスライブラリに必ず含まれているRuntimeクラスに似た機能を備えています。コンソール出力を行うコマンドラインアプリケーションから出力を取得するには、独立した1つのスレッドと、stdoutおよびstderrの出力を取得する2つのスレッドが必要です。
私のように単にコマンドを実行してその出力を取得したいだけのプログラマにとっては、ProcessBuilderのAPIは複雑すぎます。それでも、ProcessBuilderは非常に柔軟性が高いので、やはり設計上の選択肢として捨てがたいものがあります。例えば、大量の出力を生成するコマンドの場合、stdoutスレッドに対して特殊な処理を行いたいときもあります。しかし大抵の場合は、そうしたスレッドの煩雑な面をすべてファサードの向こう側に隠しておきたいと思うでしょう。
