Si une interface hérite d'une autre interface

Question

Je n'arrive pas à trouver une réponse à cela et veulent juste s'assurer que c'est ok norme de codage. J'ai Une Interface qui est utilisée par beaucoup de classes différentes et ne veulent pas de l'interface d'Un changement. Je suis tombé sur une nouvelle exigence qui nécessitera un enum nécessaire par la plupart des classes qui Implémentent l'Interface d'Un, mais pas toutes les classes ont besoin de cette enum. Je ne veux pas les classes qui n'ont pas besoin de cette nouvelle enum pour mettre en Œuvre cette nouvelle fonctionnalité. J'ai donc créé l'Interface de B qui contient le nouveau enum que j'ai besoin d'ajouter. J'ai ensuite fait l'Interface B Hérite de l'Interface d'Un et c'est mon souci, Est-il ok pour une Interface d'Hériter d'une autre Interface? Pour continuer avec mes modifications, j'ai ensuite changé les classes nécessaires à la nouvelle enum pour Implémenter l'Interface B à la place de l'Interface d'Un depuis qu'il a été Hérité par l'Interface de B. j'ai pensé à la mise en Œuvre de deux Interfaces dans mes classes qui en ont besoin, mais je suis à l'aide de l'Interface dans le code et voudrais juste utiliser une Interface pour regarder à travers les classes et non pas deux.

J'espère que c'est suffisamment clair (probablement pour longtemps), mais si quelqu'un peut me donner quelques conseils sur ce soit je suis en train de faire ou je le fais de mal s'il vous plaît laissez-moi savoir.

Merci!

Answer 1

L'héritage d'interface est un excellent outil, bien que vous ne deviez l'utiliser que lorsque l'interface B est vraiment substituable à l'interface A, et pas seulement pour agréger des comportements vaguement liés.

Il est difficile de dire si cela convient à votre cas spécifique, mais il n'y a rien de mal à la pratique en principe. Vous le voyez tout le temps dans les API de premier ordre. Pour ne prendre qu'un exemple courant, à partir du framework .NET:

 public interface ICollection<T> : IEnumerable<T>, IEnumerable
 

Answer 2

Techniquement parlant, les interfaces ne pas hériter les uns des autres. Ce qui se passe réellement lorsque vous créez un IFoo qui hérite de IBar, vous êtes en train de dire que toute classe qui implémente IFoo devez aussi mettre en oeuvre IBar.

interface IBar
{
    void DoBar();
}

interface IFoo : IBar
{
    void DoFoo();
}

Dans cet exemple, l' IFoo interface n'a pas d' DoBar() méthode. La plupart du temps, la distinction n'a pas d'importance, mais il peut vous mordre lors de l'utilisation de la réflexion sur une interface plutôt qu'une classe.

Answer 3

Il est certainement possible d'avoir un arbre d'héritage d'interfaces, et même "l'héritage multiple" avec les interfaces. Si c'est la bonne chose à faire ou non dépend des interfaces en question. Si c'est vraiment le cas de l'interface B est une extension ou une amélioration de l'interface d'Un, puis de l'héritage de sens, mais si la nouvelle enum est en grande partie indépendants de la notion exprimée par Une interface, je voudrais faire deux interfaces et ont les classes qui en ont besoin pour mettre en œuvre les deux interfaces.

Answer 4

Je pense que les bases de données de toujours fournir un excellent moyen de démontrer les interfaces, afin d'examiner si une interface doit hériter d'une autre interface de regarder la suite,

IMySqlDatabase : IDatabase
MySqlDatabase : IMySqlDatabase

IMsSqlDatabase : IDatabase
MsSqlDatabase : IMsSqlDatabase

Un MySqlDatabase EST un IMySqlDatabase et un IMySqlDatabase EST un IDatabase.

Maintenant, si vous avez besoin d'apporter des modifications à votre IDatabase interface c'est des petits-enfants (en béton classes de base de données) peuvent profiter des avantages, mais vous n'aurez pas à élargir MySQL ET MsSQL (ou peut-être même plus SGBD Interfaces). Au même moment, dans votre milieu de l'homme (IMsSqlDatabase), vous pouvez toujours avoir des fonctionnalités de l'interface que MySQL ou Oracle DB ne supporterais pas.

Answer 5

OMI, c'est exactement la bonne approche, je n'y vois aucun problème.