Est-il OK que les interfaces dépendent de classes concrètes?

Je crée une interface en Java pour le gestionnaire d'erreurs personnalisé.

Je veux passer un objet d'erreur d'argument mais j'en ai besoin pour être un enfant de Exceptionclasse.

Est-il correct d'utiliser mon nom de classe défini dans une interface?

Cela n'en fera-t-il pas moins une interface en termes de ne dépendre d'aucune implémentation?

J'essaie de faire quelque chose comme ça:

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

public interface Interface {

    void onError(CustomException ex);

}

Tout d' abord , je dois souligner le fait que CustomExceptionne couvre pas Exceptionil est pas vraiment un Exception.

Cela dit:

Si vous ne vous souciez pas du principe d'inversion de dépendance , laissez-le tel quel. Il est parfaitement normal qu'une interface dépende de classes concrètes, par exemple de nombreuses interfaces dépendent Stringou Objectqui sont des classes concrètes . Le fait est que nous aurions tendance à croire que les classes qui appartiennent au SDK Java sont plus stables (moins sujettes aux changements de rupture de code) que celles que nous écrivons.

D'un autre coté:

Si vous souhaitez suivre le DIP (qui a d'innombrables avantages et est ma recommandation), vous devez faire l'une des deux choses suivantes:

Option 1

• Faire un CustomExceptionrésumé
• Gardez void onError(CustomException ex)tel quel

Option 2

• Faire CustomExceptionune interface
• Gardez void onError(CustomException ex)tel quel

Avec l'une ou l'autre de ces options, vous seriez conforme au DIP, car l'interface ne dépendrait d'aucune classe concrète, seulement d'abstractions.

Dans une application directe de l'inversion de dépendance, les résumés appartiennent aux couches supérieures / politiques. Cette architecture regroupe les composants supérieurs / politiques et les résumés qui définissent les services inférieurs ensemble dans le même package. Les couches de niveau inférieur sont créées par héritage / implémentation de ces classes ou interfaces abstraites . Martin, Robert C. (2003).

• Développement de logiciels agiles, principes, modèles et pratiques. Prentice Hall. pp. 127–131. ISBN 978-0135974445.

Tulains a raison - les interfaces dépendent tout le temps de classes concrètes. Ils sont uniquement destinés à créer un contrat pour leurs propres préoccupations. Ce contrat peut impliquer la prise et le retour de tout type de données.

N'oubliez pas que dans les langues de niveau supérieur, même les types primitifs ne le sont pas. Vous travaillez donc avec des types de béton de toute façon!

Je suppose que par nom , vous voulez dire la classe elle-même. Si vous essayez de spécifier le nom de la classe d'exception réelle afin d'initialiser l'exception correspondante via Reflection, ce n'est pas la bonne solution.

Si vous souhaitez utiliser une classe personnalisée dans une interface, vous pouvez bien sûr utiliser vos propres classes dans vos propres interfaces. Les classes deviennent des parties de l'interface publique de votre bibliothèque / API. Les structures de données et les exceptions sont un bon exemple des classes qui sont souvent utilisées par les interfaces.

Si vous devez utiliser différentes exceptions en fonction du contexte, vous pouvez être intéressé par l'utilisation de génériques.