Quand dois-je utiliser une structure au lieu d'une classe?

MSDN dit que vous devez utiliser des structures lorsque vous avez besoin d'objets légers. Y a-t-il d'autres scénarios où une structure est préférable à une classe?

Certaines personnes ont peut-être oublié que:

1. les structures peuvent avoir des méthodes.
2. les structures ne peuvent pas être héritées.

Je comprends les différences techniques entre les structures et les classes, je ne sais tout simplement pas quand utiliser une structure.

MSDN a la réponse: choisir entre les classes et les structures .

Fondamentalement, cette page vous donne une liste de contrôle en 4 points et dit d'utiliser une classe à moins que votre type ne réponde à tous les critères.

Ne définissez une structure que si le type possède toutes les caractéristiques suivantes:

• Il représente logiquement une valeur unique, similaire aux types primitifs (entier, double, etc.).
• Il a une taille d'instance inférieure à 16 octets.
• C'est immuable.
• Il n'aura pas à être emballé fréquemment.

Je suis surpris de n'avoir lu aucune des réponses précédentes, que je considère comme l'aspect le plus crucial:

J'utilise des structures lorsque je veux un type sans identité. Par exemple un point 3D:

public struct ThreeDimensionalPoint
{
    public readonly int X, Y, Z;
    public ThreeDimensionalPoint(int x, int y, int z)
    {
        this.X = x;
        this.Y = y;
        this.Z = z;
    }

    public override string ToString()
    {
        return "(X=" + this.X + ", Y=" + this.Y + ", Z=" + this.Z + ")";
    }

    public override int GetHashCode()
    {
        return (this.X + 2) ^ (this.Y + 2) ^ (this.Z + 2);
    }

    public override bool Equals(object obj)
    {
        if (!(obj is ThreeDimensionalPoint))
            return false;
        ThreeDimensionalPoint other = (ThreeDimensionalPoint)obj;
        return this == other;
    }

    public static bool operator ==(ThreeDimensionalPoint p1, ThreeDimensionalPoint p2)
    {
        return p1.X == p2.X && p1.Y == p2.Y && p1.Z == p2.Z;
    }

    public static bool operator !=(ThreeDimensionalPoint p1, ThreeDimensionalPoint p2)
    {
        return !(p1 == p2);
    }
}

Si vous avez deux instances de cette structure, vous ne vous souciez pas s'il s'agit d'une seule donnée en mémoire ou de deux. Vous vous souciez juste de la valeur (s) qu'ils détiennent.

Bill Wagner a un chapitre à ce sujet dans son livre "effective c #" ( http://www.amazon.com/Effective-Specific-Ways-Improve-Your/dp/0321245660 ). Il conclut en utilisant le principe suivant:

1. Est la responsabilité principale du type de stockage de données?
2. Son interface publique est-elle entièrement définie par des propriétés qui accèdent ou modifient ses membres de données?
3. Êtes-vous sûr que votre type n'aura jamais de sous-classes?
4. Êtes-vous sûr que votre type ne sera jamais traité de manière polymorphe?

Si vous répondez «oui» aux 4 questions: utilisez une structure. Sinon, utilisez une classe.

Utilisez une structure lorsque vous voulez une sémantique de type valeur au lieu de type référence. Les structures sont copiées par valeur, alors faites attention!

Voir également les questions précédentes, par exemple

Quelle est la différence entre struct et class dans .NET?

J'utiliserais des structures lorsque:

1. un objet est censé être en lecture seule (chaque fois que vous passez / assignez une structure, il est copié). Les objets en lecture seule sont parfaits en matière de traitement multithread car ils ne nécessitent pas de verrouillage dans la plupart des cas.

2. un objet est petit et de courte durée. Dans un tel cas, il y a de fortes chances que l'objet soit alloué sur la pile, ce qui est beaucoup plus efficace que de le placer sur le tas managé. De plus la mémoire allouée par l'objet sera libérée dès qu'elle sortira de sa portée. En d'autres termes, c'est moins de travail pour Garbage Collector et la mémoire est utilisée plus efficacement.

Utilisez une classe si:

• Son identité est importante. Les structures sont copiées implicitement lorsqu'elles sont passées par valeur dans une méthode.
• Il aura une grande empreinte mémoire.
• Ses champs nécessitent des initialiseurs.
• Vous devez hériter d'une classe de base.
• Vous avez besoin d'un comportement polymorphe;

Utilisez une structure si:

• Il agira comme un type primitif (int, long, octet, etc.).
• Il doit avoir une petite empreinte mémoire.
• Vous appelez une méthode P / Invoke qui nécessite le passage d'une structure par valeur.
• Vous devez réduire l'impact de la récupération de place sur les performances des applications.
• Ses champs doivent être initialisés uniquement à leurs valeurs par défaut. Cette valeur serait zéro pour les types numériques, false pour les types booléens et null pour les types de référence.
  • Notez qu'en C # 6.0, les structures peuvent avoir un constructeur par défaut qui peut être utilisé pour initialiser les champs de la structure à des valeurs non par défaut.
• Vous n'avez pas besoin d'hériter d'une classe de base (autre que ValueType, dont toutes les structures héritent).
• Vous n'avez pas besoin d'un comportement polymorphe.

J'ai toujours utilisé une structure lorsque je voulais regrouper quelques valeurs pour renvoyer des choses à partir d'un appel de méthode, mais je n'aurai pas besoin de l'utiliser pour quoi que ce soit après avoir lu ces valeurs. Tout comme un moyen de garder les choses propres. J'ai tendance à voir les choses dans une structure comme "jetables" et les choses dans une classe comme plus utiles et "fonctionnelles"

Si une entité doit être immuable, la question de l'utilisation d'une structure ou d'une classe sera généralement une question de performance plutôt que de sémantique. Sur un système 32/64 bits, les références de classe nécessitent 4/8 octets à stocker, quelle que soit la quantité d'informations dans la classe; la copie d'une référence de classe nécessite la copie de 4/8 octets. D'autre part, tous distinctsl'instance de classe aura 8/16 octets de surcharge en plus des informations qu'elle contient et du coût de la mémoire des références. Supposons que l'on veuille un tableau de 500 entités, chacune contenant quatre entiers 32 bits. Si l'entité est un type de structure, le tableau nécessite 8 000 octets, que les 500 entités soient toutes identiques, toutes différentes ou quelque part entre les deux. Si l'entité est un type de classe, le tableau de 500 références prendra 4 000 octets. Si ces références pointent toutes vers des objets différents, les objets nécessiteraient 24 octets supplémentaires chacun (12 000 octets pour les 500), soit un total de 16 000 octets, soit le double du coût de stockage d'un type struct. D'un autre côté, du code a créé une instance d'objet, puis copié une référence aux 500 emplacements de tableau, le coût total serait de 24 octets pour cette instance et 4, 000 pour la baie - un total de 4 024 octets. Une économie importante. Peu de situations fonctionneraient aussi bien que la dernière, mais dans certains cas, il peut être possible de copier certaines références dans suffisamment d'emplacements de tableau pour que ce partage en vaille la peine.

Si l'entité est censée être mutable, la question de savoir s'il faut utiliser une classe ou une structure est à certains égards plus facile. Supposons que "Thing" soit une structure ou une classe qui a un champ entier appelé x, et on fait le code suivant:

  Chose t1, t2;
  ...
  t2 = t1;
  t2.x = 5;

Veut-on que cette dernière instruction affecte t1.x?

Si Thing est un type de classe, t1 et t2 seront équivalents, ce qui signifie que t1.x et t2.x seront également équivalents. Ainsi, la deuxième instruction affectera t1.x. Si Thing est un type de structure, t1 et t2 seront des instances différentes, ce qui signifie que t1.x et t2.x feront référence à des entiers différents. Ainsi, la deuxième instruction n'affectera pas t1.x.

Les structures mutables et les classes mutables ont des comportements fondamentalement différents, bien que .net ait quelques bizarreries dans sa gestion des mutations struct. Si l'on veut un comportement de type valeur (ce qui signifie que "t2 = t1" copiera les données de t1 vers t2 tout en laissant t1 et t2 comme des instances distinctes), et si l'on peut vivre avec les caprices de la gestion des types de valeur par .net, utilisez une structure. Si l'on veut une sémantique de type valeur mais que les caprices de .net entraîneraient une sémantique de type valeur cassée dans son application, utilisez une classe et marmonnez.

De plus, les excellentes réponses ci-dessus:

Les structures sont des types de valeur.

Ils ne peuvent jamais être définis sur Nothing .

Définir une structure = Rien, mettra tous ses types de valeurs à leurs valeurs par défaut.

lorsque vous n'avez pas vraiment besoin de comportement, mais que vous avez besoin de plus de structure qu'un simple tableau ou dictionnaire.

Suivi Voici comment je pense aux structures en général. Je sais qu'ils peuvent avoir des méthodes, mais j'aime garder cette distinction mentale globale.

Comme l'a dit @Simon, les structures fournissent une sémantique de "type valeur", donc si vous avez besoin d'un comportement similaire à un type de données intégré, utilisez une structure. Puisque les structures sont passées par copie, vous voulez vous assurer qu'elles sont de petite taille, environ 16 octets.

C'est un sujet ancien, mais je voulais fournir un test de référence simple.

J'ai créé deux fichiers .cs:

public class TestClass
{
    public long ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

et

public struct TestStruct
{
    public long ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Exécuter le benchmark:

• Créer 1 classe de test
• Créer 1 TestStruct
• Créer 100 TestClass
• Créer 100 TestStruct
• Créer 10000 TestClass
• Créer 10000 TestStruct

Résultats:

BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.1.101
[Host]     : .NET Core 3.1.1 (CoreCLR 4.700.19.60701, CoreFX 4.700.19.60801), X64 RyuJIT  [AttachedDebugger]
DefaultJob : .NET Core 3.1.1 (CoreCLR 4.700.19.60701, CoreFX 4.700.19.60801), X64 RyuJIT


|         Method |           Mean |         Error |        StdDev |     Ratio | RatioSD | Rank |    Gen 0 | Gen 1 | Gen 2 | Allocated |
|--------------- |---------------:|--------------:|--------------:|----------:|--------:|-----:|---------:|------:|------:|----------:|

|      UseStruct |      0.0000 ns |     0.0000 ns |     0.0000 ns |     0.000 |    0.00 |    1 |        - |     - |     - |         - |
|       UseClass |      8.1425 ns |     0.1873 ns |     0.1839 ns |     1.000 |    0.00 |    2 |   0.0127 |     - |     - |      40 B |
|   Use100Struct |     36.9359 ns |     0.4026 ns |     0.3569 ns |     4.548 |    0.12 |    3 |        - |     - |     - |         - |
|    Use100Class |    759.3495 ns |    14.8029 ns |    17.0471 ns |    93.144 |    3.24 |    4 |   1.2751 |     - |     - |    4000 B |
| Use10000Struct |  3,002.1976 ns |    25.4853 ns |    22.5920 ns |   369.664 |    8.91 |    5 |        - |     - |     - |         - |
|  Use10000Class | 76,529.2751 ns | 1,570.9425 ns | 2,667.5795 ns | 9,440.182 |  346.76 |    6 | 127.4414 |     - |     - |  400000 B |

Hmm ...

Je n'utiliserais pas la récupération de place comme argument pour / contre l'utilisation de structures vs classes. Le tas géré fonctionne un peu comme une pile - la création d'un objet le place simplement en haut du tas, ce qui est presque aussi rapide que l'allocation sur la pile. De plus, si un objet est de courte durée et ne survit pas à un cycle de GC, la désallocation est gratuite car le GC ne fonctionne qu'avec de la mémoire qui est toujours accessible. (Recherchez MSDN, il y a une série d'articles sur la gestion de la mémoire .NET, je suis juste trop paresseux pour aller les chercher).

La plupart du temps, j'utilise une structure, je finis par me donner des coups de pied parce que je découvre plus tard qu'avoir une sémantique de référence aurait rendu les choses un peu plus simples.

Quoi qu'il en soit, ces quatre points dans l'article MSDN publié ci-dessus semblent être une bonne ligne directrice.

Les structures sont sur la pile et non sur le tas, donc elles sont thread-safe et doivent être utilisées lors de l'implémentation du modèle d'objet de transfert, vous ne voulez jamais utiliser d'objets sur le tas, elles sont volatiles, vous voulez dans ce cas utiliser la pile d'appels, ceci est un cas de base pour utiliser une structure, je suis surpris par toutes les réponses ici,

Je pense que la meilleure réponse est simplement d'utiliser struct quand ce dont vous avez besoin est une collection de propriétés, classe quand c'est une collection de propriétés ET de comportements.