設計に関する FAQ - 一般的な質問

1. 特別なサポートなしで Java プログラミング言語上にアサーションをプログラムできるのにアサーション機能を提供するのはなぜでしょうか。

   アドホックな実装も可能ですが、アサーション機能は必然的に見た目が悪く(アサーションごとに if 文が必要)、非効率的です (アサーションが無効の場合でも状態を評価する)。さらに、アドホックな実装はそれぞれ独自のアサーションを有効または無効にする手段を持つことになるので、特に、フィールドでのデバッグにおいてこのような実装の利点を失ってしまいます。これらの欠点のために、アサーションは Java の機能として取り入れられませんでした。アサーションのサポートがプラットフォームに追加されれば、この状況は改善されるでしょう。

2. アサーションの実装にライブラリではなく言語の変更が採用されたのはなぜでしょうか。

   言語の変更は簡単ではなく、たいへんな努力が必要です。ライブラリによるアプローチも考えました。しかし、アサーションを無効にした場合の実行時コストがごくわずかになることが重要であると判断しました。これをライブラリで行おうとすると、プログラマは各アサーションを if 文としてハードコードする必要があります。ほとんどのプログラマはこのような作業を行いたくはありません。その場合 if 文を省略して性能を落とすか、またはアサーション機能を完全に無視します。実は、James Gosling による Java の最初の仕様にはアサーション機能が含まれていました。しかし、時間の制約のために十分な設計および実装ができなかったため、Oak 仕様から削除されました。

3. Eiffel プログラミング言語のように、事前条件、事後条件、およびクラス不変条件に、「規約による設計」機能を本格的に提供しなかったのはなぜでしょうか。

   このような機能を提供することも考えましたが、Java プラットフォームライブラリを大幅に変更せずに、しかも、古いライブラリと新しいライブラリ間の不整合を最小限に抑えながら、このような機能を Java プログラミング言語に実装できるかどうかに確信が持てませんでした。さらに、このような機能が Java の最大の特徴である簡易性を損なわないかどうかにも確信が持てませんでした。すべてを考慮して、単純な boolean 型のアサーション機能がもっとも簡単なソリューションであり、もっともリスクが少ないと結論付けました。ただし、boolean 型のアサーション機能を言語に追加したと言っても、将来、「規約による設計」機能を本格的に追加する可能性を否定するわけではありません。

   単純なアサーション機能は、制限はあるものの、「規約による設計」スタイルのプログラミングを実現します。assert 文は事後条件とクラス不変条件のチェックに適切です。事前条件のチェックは依然、指定された特別な例外 (IllegalArgumentException や IllegalStateException など) を生成するメソッド内で行う必要があります。

4. boolean 型のアサーションとは別に、アサーションが無効になっている場合にコード全体の実行を抑制するような (アサーションに似た) 機能を提供しなかったのはなぜでしょうか。

   このような機能を提供すると、プログラマは、別のメソッドを使用した方がいい場合でも、複雑なアサーションをインライン化してしまう可能性があるためです。