Êtes-vous capable de définir des implémentations de classe dans une interface?
Par exemple (alerte pseudo-code!) ...
6 Réponses :
non. En outre, la classe2 n'est pas une sous-classe, c'est une classe ou une classe intérieure imbriquée. "Sous-classe" est (dans ce contexte, il existe d'autres contextes qui sont complètement différents) un autre nom pour une classe dérivée, dans quel contexte la classe de base s'appelle une "super-classe" (c'est pourquoi Java a un mot clé < Code> Super qui est analogue à Les classes intérieures utilisent essentiellement leur classe contenant comme espace de noms et rien d'autre, tout en interface uniquement les méthodes et les propriétés des membres. base en C # avec quelques différences). "Dérivé" et "base" sont les termes les plus populaires en C #, peut-être parce qu'ils sont des termes plus populaires en C ++, peut-être parce que Bjarne Stroustrup a déclaré qu'il leur trouve déroutant et qu'il se mêle à ce qui est la sous-classe (après tout, la sous-classe a un superset de comportement et vice-versa).
Il n'y a pas de syntaxe pour forcer une classe à mettre en œuvre une autre classe imbriquée. Ce que vous avez défini efficacement ici, c'est que tout Malheureusement, il y a deux choses qui ne vont pas avec ceci:
iCLASS1 doit avoir un champ de type classe2 .
classe2 ne résout pas à un type accessible connu, une erreur de compilateur sera donc générée.
(code> membre iclass1 est déclarée sous forme de champ et les interfaces ne peuvent pas déclarer champs.
Le but d'une interface est de définir un contrat Ce que vous pouvez faire avec une interface est la définition d'un
@roosteronacid: Est-ce votre réponse préférée?
Tout d'abord, votre question était la suivante:
"Êtes-vous capable de définir des implémentations de classe dans une interface?"
La réponse à ceci est "d'une manière / non" . Vous ne devriez probablement pas essayer de mettre en œuvre votre structure d'interface décrite à moins que les classes n'existaient que les fonctionnalités du code de mise en œuvre dépendent totalement et si l'interface est déjà profondément intégrée à plusieurs modules existants. Que soi-même est une faille de conception et pourrait être échangée avec une implémentation de classe abstraite. obliger les classes à hériter d'une seule classe de base ferait dans la plupart des cas la hiérarchie de la classe trop inflexible. Pour utiliser une classe de base en interne pour simplifier le développement de la bibliothèque, les membres du secteur public devraient déléguer travailler à la classe de base au lieu de lui en hériter.
Choisissez avec soin entre une classe abstraite et une interface lors de la conception d'une abstraction telle qu'elle peut se comporter comme une interface dans laquelle il peut définir des membres, et il peut fournir des détails de la mise en œuvre mais sont < Strong> pas obligé de le faire , et peut ajouter des membres au besoin pour soutenir des fonctionnalités supplémentaires ...
Donc, s'il est utilisé dans la manière dont vous voulez, il démarre à partir du concept d'interfaces C #, mais il semblerait peut-être plus près d'imiter le modèle de multiples héritages de langues telles que C ++ dans la pratique, car elle "force tous les accompagnateurs de votre Interface pour créer une instance de chaque classe que l'interface a spécifié des propriétés pour. Donc, même si c'est une solution possible, je n'appellerais pas cela un bon moyen de concevoir des objets ...
Vous ne pouvez pas inclure les définitions de classe "à l'intérieur" la définition de l'interface si c'est ce que vous voulez dire.
Comme mentionné précédemment, la mise en œuvre d'une telle chose pourrait se produire via des propriétés d'interface.
Le CLR ne prend pas en charge de multiples héritage, mais il permet aux types d'implémenter une ou plusieurs interfaces en plus de hériter d'une classe de base. Par conséquent, les interfaces sont souvent utilisées pour atteindre l'effet de multiples héritage.
Vous devez penser un peu sur la raison pour laquelle vous souhaitez créer une telle structure (la nécessité de forcer tous les implémentations d'une interface pour créer également des instances de classes que l'interface définit en tant que propriétés).
C'est plus probablement une conception défaut dans votre code qu'il ne s'agit d'une fonctionnalité de langue manquante.
excuses si j'ai mal compris mais, oui, je le fais maintenant (VB 2013 pour .NET 4.0 & 4.5). Les interfaces peuvent définir des propriétés, les propriétés peuvent être complexes, la définition de la classe pour laquelle peut être imbriquée dans la définition de l'interface. Dans votre classe qui implémente l'interface, vous ne pouvez avoir qu'un getter / setter pour l'objet complexe dans son ensemble et non pour ses propriétés individuelles. (Les getters / setters pour ceux-ci sont dans la définition de la classe bien sûr). Exemple de fonctionnement de VB attaché, avec une conversion non testée à C #.
vb: et c #:
FYI - La version C # ne compilera pas. C # n'autorise pas les classes dans les interfaces.
Je suis incapable de commenter, mais la réponse acceptée à cette question n'est plus exacte. À partir du C # 8, il est possible de définir des implémentations par défaut pour les méthodes d'interface. Comme les interfaces n'ont aucun membre privé, cela se limite à appeler d'autres membres publics, ce qui est utile pour la définition des remplacements de méthode qui vous appellent.