「インターフェースへのコード」は良い習慣と考えられています。このようなコードは単体テストが容易で、疎結合が可能です。ユーザーはインターフェイスだけを知っており、具体的なオブジェクトを配線する責任は最上位レベルにあります (これは、いくつかの初期化コードで、またはフレームワークの助けを借りて行うことができます)。
私の質問は、インターフェースへのコードの実践に従うことについてです:具象クラスは、そのインターフェースに存在しないパブリックメソッドを決して宣言できないことを意味しますか?
そうしないと、ユーザーは具体的な実装に依存することになります。これにより、そのようなメソッドの単体テストが難しくなります。テストが失敗した場合、呼び出し元コードの問題が原因で失敗したのか、具体的なメソッドが原因で失敗したのかを判断するには、余分な労力が必要です。これは、依存関係逆転の原則にも違反します。これは、悪い習慣と見なされる型チェックとダウンキャストを引き起こします。
新しいメソッドがクラスの操作、特に誰かがそれをスーパークラスまたはインターフェースと見なしたときにどのように機能するかにとって重要でない限り、それは完全に受け入れられます。
ArrayList は良い例を提供します。ensureCapacity(int)やなど、内部メモリを管理できるメソッドがありますtrimToSize()。これらは、ArrayList を使用していて、メモリの割り当てについてより正確にする必要があることがわかっている場合に役立つことがありますが、ArrayList の基本的な操作には必要ありません。一般的なリストとして機能します。
実際、インターフェース自体は、この方法で新しいメソッドを追加できます。Set を拡張するNavigableSetを検討してください。セットの要素の順序付けに依存する一連のメソッドを追加します (最初、最後、ここから始まるサブツリーなどを教えてください)。これらのメソッドはいずれも Set で定義されておらず、要素が順序付けられているという事実でさえ、Set コントラクトによって定義されていません。ただし、Set メソッドはすべて、追加のメソッドや順序付けがなくても問題なく機能します。
「インターフェイスにコーディングする」というアドバイスは良い出発点ですが、少し一般化されすぎています。そのアドバイスを改良すると、「必要な最も一般的なインターフェイスにコーディングする」ということになります。ArrayLists のメソッド (またはそのランダム アクセス パフォーマンスなどのコントラクト) が必要ない場合は、List にコーディングします。しかし、それらが必要な場合は、ぜひ使用してください。