一定のインターフェース

Java プログラミング言語では、定数インターフェースパターンは、定数を定義するためだけにインターフェースを使用し、クラスがそのインターフェースを実装することで、それらの定数に構文的に簡単にアクセスできるようにすることを説明しています。しかし、定数は多くの場合単なる実装の詳細であり、クラスによって実装されるインターフェースはそのクラスのエクスポートされた API の一部であるため、この方法は実装の詳細を API に組み込むことになり、Java 設計者のJoshua Bloch氏などによって不適切だと考えられていました。^{[ 1 ]}一般的に、動作とは無関係にシステム定数をクラスにまとめることは、凝集度が低いことの兆候であることが多いため、オブジェクト指向設計としては不適切になる可能性があります。これらの理由から、定数インターフェースはアンチパターンと見なされることがあります。

このパターンを使用することには、他にもいくつかの欠点があります。

1. これは、役に立たない可能性のある読み取り専用変数でクラス名前空間を汚染します。
2. 定数インターフェースを実装することによるコンパイル時の戦術的な有用性とは対照的に、偶発的に発生する実行時アーティファクトには実用的な目的がほとんどない（メソッドを持たないが実行時に有用なマーカーインターフェースを参照）。
3. 将来のリリースでバイナリコードとの互換性が求められる場合、定数インターフェースは、従来の意味でのインターフェースとして使用されていなくても、常にインターフェースのままでなければなりません（クラスに変換することはできません）。
4. 定数がどこから来ているのかを解決できるIDEがない場合、定数を包含するクラスやインターフェースまで遡って追跡するのは時間がかかる可能性があります。
5. インターフェースのインスタンスは、構文的にはインターフェース名自体と比べて何ら有用性はありません（メソッドを持たないため）。
6. 開発者がクラスに定数を追加する際に実装されているインターフェースを確認しない限り、あるいは確認したとしても追加する定数の名前にタイプミスをしない限り、定数の値は知らず知らずのうちに変更されてしまう可能性があります。以下の例2をご覧ください。

Javaライブラリ自体が定数インターフェースパターンを使用していることに注意してください。たとえば、SwingConstantsインターフェース^{[ 2 ]}は1998年にリリースされ^{[ 3 ]}、当時は妥当な選択でした。

パブリックインターフェース定数{public static final int CONSTANT = 1 ; }public class Class1 implements Constants {public static final int CONSTANT = 2 ; // *public static void main ( String args [] ) throws Exception { System . out . println ( CONSTANT ); } }

アスタリスク(*)が付いた行を追加する前は、Class1を実行すると1が出力されます。その行を追加した後は、Class1は2を出力します。どちらのバージョンも警告やエラーなくコンパイルされます。

アンチパターンの多くの落とし穴は、定数インターフェースを静的属性を持つクラスに変換することで回避できます。

public final class Constants {private Constants () { // インスタンス化を制限する}public static final double PI = 3.14159 ; public static final double PLANCK_CONSTANT = 6.62606896e-34 ; }

Java 5以降では、静的インポート^{[ 4 ]}を使用することで、定数修飾子なしで定数を使用できるようになります。

import static Constants.PLANCK_CONSTANT ; import static Constants.PI ;public class Calculations {public double getReducedPlanckConstant () { return PLANCK_CONSTANT / ( 2 * PI ); } }

定数は、`import static Constants.*`ステートメントを使用することで一括インポートすることもできます。これにより、インターフェースを使用する場合と同じ目的が達成され、修飾子なしで定数を参照できるようになります。

上記の問題点は、程度の差こそあれ、現在では解決されている。

1. 静的メンバーは個別にインポートできるため、クラス名前空間を定数インターフェースのすべてのメンバーで汚染する必要はありません。
2. 定数インターフェースの代わりに静的インポートを使用すると、実行時とコンパイル時のセマンティクスがより密接に一致する。
3. コンパイルされたコードには、バイナリ互換性の制約が1つ少なくなっています（「クラスCalculationsはConstantsを実装する」）。
4. 静的インポートは現在のファイルのみに適用され（クラス階層全体には適用されない）、各静的メンバーがどこで宣言されているかを容易に特定できます。
5. 定数インターフェース型の変数を宣言する必要性が少なくなり、具体的なインスタンスが実際には存在しないことがより明確になる可能性があります。

ただし、これらの変更はConstants クラスの凝集度を向上させるものではなく、定数の値が意図せずサイレントに変更されるのを防ぐものでもないため、静的インポートは万能薬とは考えない方が良いでしょう。