インターフェースが具象クラスに依存することは問題ありませんか？

カスタムエラーハンドラーのJavaでインターフェイスを作成しています。

引数エラーオブジェクトを渡したいのですが、Exceptionクラスの子である必要があります。

定義したクラス名をインターフェイスで使用しても大丈夫ですか？

実装に依存しないという点で、インターフェースを少なくしませんか？

私はこのようなことをやろうとします：

public class CustomException {
    /* ... Implementation ... */
}

public interface Interface {

    void onError(CustomException ex);

}

最初に私はCustomException拡張しないという事実を指摘しなければならないExceptionので、それは実際にはありませんException。

それは言った：

Dependency Inversion Principleを気にしない場合は、そのままにしておきます。インターフェースが具象クラスに依存することは完全に問題ありません。たとえば、多くのインターフェースは具象クラスに依存している、StringまたはObject具象クラスです。問題は、Java SDKに属するクラスは、私たちが作成したクラスよりも安定している（コードを壊す変更が少ない）と信じがちなことです。

その一方で：

DIP（無数の利点があり、私の推奨事項です）をフォローしたい場合は、次の2つのいずれかを行う必要があります。

オプション1

• 作るCustomException抽象
• キープvoid onError(CustomException ex)そのまま

オプション2

• CustomExceptionインターフェースを作る
• キープvoid onError(CustomException ex)そのまま

これらのオプションのいずれかを使用すると、インターフェイスは具体的なクラスに依存せず、抽象化にのみ依存するため、DIPに準拠します。

依存関係の逆転の直接適用では、抽象は上位層/ポリシー層によって所有されます。このアーキテクチャは、上位/ポリシーコンポーネントと下位サービスを定義する抽象を同じパッケージにまとめたものです。下位層は、これらの抽象クラスまたはインターフェースの継承/実装によって作成されます。マーティン、ロバートC（2003）。

• アジャイルソフトウェア開発、原則、>パターン、および実践。プレンティスホール。127-131ページ。ISBN 978-0135974445。

Tulainsは正解です。インターフェースは常に具象クラスに依存しています。彼らは彼ら自身の懸念のために契約を作成することのみを意図しています。その契約には、あらゆる種類のデータの取得と返却が含まれます。

高水準言語では、プリミティブ型でもそれほどプリミティブではないことに注意してください。とにかくあなたは具体的なタイプで作業しています！

名前からすると、実際のクラス自体を意味していると思います。Reflectionを介して対応する例外を初期化するために実際の例外クラス名を指定しようとしている場合、これは正しい方法ではありません。

インターフェイスでカスタムクラスを使用する場合は、もちろん、独自のインターフェイスで独自のクラスを使用できます。クラスは、ライブラリ/ APIのパブリックインターフェイスの一部になります。データ構造と例外は、インターフェースでよく使用されるクラスの良い例です。

コンテキストに応じて異なる例外を使用する必要がある場合は、ジェネリックスの使用に興味があるかもしれません。