インターフェースが具象クラスに依存することは問題ありませんか？
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は正解です。インターフェースは常に具象クラスに依存しています。彼らは彼ら自身の懸念のために契約を作成することのみを意図しています。その契約には、あらゆる種類のデータの取得と返却が含まれます。
高水準言語では、プリミティブ型でもそれほどプリミティブではないことに注意してください。とにかくあなたは具体的なタイプで作業しています！
nameと思いますが、実際のクラス自体を意味します。 Reflectionを介して対応する例外を初期化するために実際の例外クラスnameを指定しようとしている場合、これは正しい方法ではありません。
インターフェイスでカスタムクラスを使用する場合は、もちろん、独自のインターフェイスで独自のクラスを使用できます。クラスは、ライブラリ/ APIのパブリックインターフェイスの一部になります。データ構造と例外は、インターフェースでよく使用されるクラスの良い例です。
コンテキストに応じて異なる例外を使用する必要がある場合は、ジェネリックスの使用に興味があるかもしれません。