いくつかのサブタイプがあり、それぞれが抽象スーパークラスを継承し、このスーパークラスがインターフェイスを実装している場合-動的バインディング/ポリモーフィズムを実装する場合、オブジェクトをインターフェイスタイプではなく、スーパークラスタイプとして宣言することに違いはありますか？
したがって、A、B、C、DはSから拡張され、SはIを実装します。
私はそれをできた：
S a = new A();
S b = new B();
また
I a = new A();
I b = new B();
私はインターフェイスを使用する傾向がありますが、インターフェイスを2つのインターフェイスに分割する場合に備えて、スーパークラスを使用する方がよいかどうか突然疑問に思います。
タイピングの観点からは、違いはありません。（リフレクションを使用して実行時にタイプをイントロスペクトすることで特に「探しに行く」場合を除きます...）
実行時のパフォーマンスの観点からは、違いはありません。（クラスをロードする時間のいくつかの可能な非常に小さな違いを除いて...すべての現実的なユースケースで無視することができます。）
コード実装の観点から、2つのアプローチには長所と短所があります。
スーパークラスのみ（インターフェースなし）を使用する場合は、記述できるコードが少なくなる可能性があります。ただし、逆に、コードの柔軟性が低くなります。
新しい実装を作成する能力を制限する方法で、実装に対する外部APIを試しています。java.io.OutputStreamクラスはこの典型的な例です。これはクラスであるため、新しいストリームタイプを実装するにはサブクラスを作成する必要があり、「継承」するすべてのインフラストラクチャをオーバーライドするようにサブクラスをコーディングする必要がある場合があります。
クラスがスーパークラスを1つだけ持つことができるという事実は、ツリー型のAPI階層にさらに制限します。
クライアントは、実装クラスAPIに対してより高度にコーディングする必要があります...これですべてです。そして、それはプログラマーが彼/彼女の考えを変える能力を制限します。
結論：特定のユースケースでこれらのことを実行できる必要がない場合（現在または将来）、インターフェイスを使用してもメリットはありません。しかし、実際にそのようなユースケースはほとんどありません。また、インターフェースを使用するための段階的な実装作業はわずかです。
追加する必要があります、私はインターフェースを使用するかどうかを尋ねていません。インターフェイスは、誰かにメソッドを実装するように強制するためだけに使用できると思います（そして型として宣言されることはありません）？
ええ。しかし、メソッドを抽象化することもできます。これは、インターフェイスを使用する本当のポイントではありません。本当のポイントは、そのインターフェースです。
オブジェクトタイプがポリモーフィズムにもたらすので、インターフェイスを使用するとどのようなメリットがありますか？
タイピングとパフォーマンスレベルから：なし-上記を参照してください。
実装階層を越える方法でインターフェースを使用すると、クライアントレベルでの柔軟性が向上すると主張できると思います。それを「ポリモーフィズムのメリット」と呼べるかもしれません。（対照的に、インターフェイス階層が実装クラス階層を正確に反映している場合は、おそらく何も達成されていません...少なくとも記述されたコードに関しては。）
しかし、ポリモーフィズムはそれ自体が目標ではなく、目的を達成するための手段であるため、抽象的な意味での「ポリモーフィズムのメリット」について質問することには意味がありません。本当のポイントは、意味のある方法でプログラムを設計および実装し、保守可能なコードを作成することです。
これは完全にコンテキストに依存します。
インスタンス化するコードは、変数を宣言するインターフェイスまたはクラスで使用可能なメンバーにのみアクセスできます。多くの場合、目標は、インスタンス化するコードがインポートするものを制限することです。について知る必要があるだけの場合はList、それをとして宣言しListます。のメソッドが必要な場合はArrayList、として宣言しArrayListます。インスタンス化するコードに必要以上のことを知らせないでください。