Hériter de la struct

Une struct Est Implicitement Scellé

Selon cette lien:

Chaque struct en C#, si elle est définie par l'utilisateur ou définis dans la .NET Framework, est scellé–ce qui signifie que vous ne pouvez pas hériter d'elle. Une structure est scellé parce que c'est un type de valeur et tous les types de valeur sont scellés.

Une struct peut implémenter une interface, il est donc possible de voir un autre type de nom à la suite d'un colon, d'après le nom de la struct.

Dans l'exemple ci-dessous, on obtient une erreur de compilation lorsque nous essayons de définir une nouvelle structure qui hérite de celui défini ci-dessus.

public struct PersonName
{
    public PersonName(string first, string last)
    {
        First = first;
        Last = last;
    }

    public string First;
    public string Last;
}

//Error at compile time: Type 'PersonName' in interface list is not an interface
public struct AngryPersonName : PersonName
{
    public string AngryNickname;
}

OriginalL'auteur One Man Crew

Types de valeur .NET sont étrange qu'ils ont défini si elles sont classes dérivées d'une classe spéciale appelée ValueType. Pour chaque type de valeur il y a un tas de type de l'objet qui se comporte comme un objet de classe qui dérive de ValueType, mais une valeur de type emplacement de stockage possède une collection d'octets qui représente une valeur primitive, ou la concaténation des octets nécessaires pour tenir l'ensemble de ses champs publiques et privées.

Étant donné que la valeur de type de sites de stockage, il suffit de tenir les octets nécessaires pour représenter leurs valeurs, et de les tenir ni le type d'information ni aucune référence à un objet qui contiendrait des informations de type, le code qui utilise une valeur de type emplacement de stockage doit savoir exactement ce qu'il est.

Classique héritage exige que les objets contiennent des informations sur leur propre type, mais il n'y a pas de disposition par l'intermédiaire de laquelle les types de valeur pourrait le faire.

Il serait théoriquement possible (et utile).NET pour permettre à certaines formes limitées de valeur-type d'héritage avec des règles spéciales, telles que tandis qu'un BaseStructure variable peut contenir seulement un BaseStructure et ne pouvait pas tenir une DerivedStructure. On pourrait définir un StructureUser<T> where T:BaseStructure, et telle classe ou méthode peut accepter que tous les dérivés de BaseStructure et l'utilisation de ces membres-y compris les champs--qui étaient courantes au type de base.

Malheureusement, il serait difficile de définir des règles pour les génériques de façon à se comporter de façon cohérente dans les permis de scénarios et encore pas tout casser code existant.

Par exemple, au sein d'une classe Foo<T,U> where T:U il est toujours possible de stocker une T à une variable de type U, même si U est un type de valeur (c'est à dire parce que les types de valeur sont scellés, T et U sont garantis la même type). Si U pourrait être un héritables type de valeur et T pourrait être un dérivé, une telle garantie ne permettrait pas de tenir.

Compte tenu des difficultés liées à un tel héritage, un plus utile alternative serait de fournir un coffre-fort (même si limitées) par lequel un bien pourrait exposer un byref ou un const-byref (byref est la chose qui est transmis lorsqu'un paramètre utilise un ref qualifier).

Une telle fonctionnalité serait de supprimer l'inévitable distinction sémantique entre les champs et les propriétés, et, selon la façon dont il a été mis en œuvre pourrait offrir de grands avantages, même lorsqu'il est utilisé avec des classes (par exemple, il pourrait permettre un mélange efficace de immuable et changeante des types).

OriginalL'auteur supercat

Structs peut implémenter une interface, mais ils ne peuvent pas hériter d'une autre structure. Pour cette raison, les membres de la structure ne peut pas être déclarée protégée.

OriginalL'auteur