Question

Cette question s'inspire de la réponse de Jon Skeet: / a>

Il fait remarquer qu'il est possible que l'ordre des champs d'un fichier ait une importance. Je suppose que cela a à voir avec l'ordre d'initialisation des champs, mais j'estime qu'il est assez dangereux de coder en fonction de cet effet secondaire pour justifier sa question et sa discussion.

Existe-t-il d'autres idées sur la manière dont l'ordre des champs dans votre fichier de code pourrait être manipulé et quel impact cela pourrait avoir?

Était-ce utile?

La solution

Voici un exemple classique tiré de la spécification du langage C # (Section 10.5.5)

class Test
{
    static int a = b + 1;
    static int b = a + 1;
    static void Main() {
        Console.WriteLine("a = {0}, b = {1}", a, b);
    }
}

Ceci est un programme complètement valide et écrit (a = 1, b = 2). Toutefois, si vous échangez l'ordre des champs, ils échangeront également des valeurs.

Autres conseils

Oui, le fait d'interagir avec du code non managé importe vraiment.

Je pensais avant tout à l'ordre d'initialisation, en particulier pour les champs statiques. Par exemple (avec des champs publics juste pour la simplicité de démonstration):

using System;

class First
{
    static int a = 10;
    public static int b = CalculateB();
    static int c = 5;

    static int CalculateB()
    {
        return a*c;
    }
}

class Second
{
    static int a = 10;
    static int c = 5;
    public static int b = CalculateB();

    static int CalculateB()
    {
        return a*c;       
    }
}

class Test
{
    static void Main()
    {
        Console.WriteLine("First.b: {0}, Second.b: {1}",
                          First.b, Second.b);
    }
}

L'ordre d'initialisation est défini dans la spécification comme étant l'ordre textuel dans lequel les variables sont déclarées - mais il devient indéfini lorsque deux variables se trouvent dans des fichiers différents contribuant à une classe partielle.

La réponse de Mehrdad est une autre bonne: tout ce dont la mise en page est importante sera probablement affecté par l'ordre de déclaration.

Si les champs sont initialisés dans le cadre de la déclaration, ils sont ajoutés au constructeur (instance ou statique) dans l'ordre dans lequel ils apparaissent dans le fichier.

Vous pouvez utiliser (abuser?) l'ordre des champs comme métadonnées de votre classe que vous pouvez lire par réflexion.

Par exemple, si vous avez une classe qui représente un protocole réseau avec les champs ID, PORT et XOR, dans cet ordre, vous pouvez le définir comme suit:

class MyProtocol {
    int ID;
    int PORT;
    int XOR;
}

Supposons maintenant que vous utilisiez la réflexion pour itérer les champs du protocole, pour l’envoyer sur le fil. La commande renvoyée par GetProperties sera celle que vous avez définie et vous n’aurez pas à écrire explicitement de métadonnées supplémentaires.

Je ne sais pas si c'est une bonne idée de dépendre de cela.

Je pense que XmlSerializer sérialise les membres dans l'ordre dans lequel ils apparaissent dans le fichier source.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top