J'ai une liste déclarée ci-dessous, au début, je par défaut les éléments de la liste à {-1, -}. Veuillez noter que tout au long du programme, la taille de la liste est fixée à 2. ma question concerne, quelle serait la meilleure approche si je dois écraser les deux valeurs de la liste. p> list[0] = x;
list[1] = y;
7 Réponses :
Peut-être que je ne comprends pas votre scénario, mais je pense qu'une meilleure solution serait un tableau simple ??
int[] list = new int[] { -1, 1 };
Personnellement, je pense que les matrices sont mauvaises. Mon but était d'essayer de les éviter.
Je vous recommanderais d'utiliser un tableau, ce qui signifie que la collection reste à une taille fixe et à la deuxième méthode pour y accéder. Ainsi: puis pour le changer: p> puisque le tableau ne change pas la taille et que 2 valeurs sont allouées à celle-ci, Vous ne recevrez pas de juste comme un de côté, vous pouvez écrire Un initialiseur pour une liste indexoutOfrangeException code>. Je n'utiliserais généralement pas la première méthode pour modifier le contenu d'une collection - en général, il est préférable de modifier un objet existant que de créer et de nouveau. P>
ou y a-t-il un plus simple et meilleur solution? p>
oui. Étant donné que la liste a une taille fixe, utilisez un véritable objet tel que Système .Drawing.point : p>
xxx pré> blockQuote>
Nice appel sur le point. Je pensais cahicotoir
+1: L'utilisation d'une liste (de la taille dynamique) crée une ambiguïté pour le type - où les commentaires doivent maintenant être invoqués à indiquer l'utilisation prévue. Si un type CLR n'est pas souhaité qu'une structure personnalisée ou un objet est appelée.
Je pense que l'utilisation du point sert le but. Je n'ai pas besoin de m'inquiéter des exceptions et de la taille est fixée à 2 !! Impressionnant!! merci Juliette!
Nifty, mais comme l'OP ne représente pas réellement un point dans un espace bidimensionnel, l'intention est embrouillée. L'approche ne fonctionnerait pas si l'OP avait 3 articles. En outre, l'API n'indique pas que x code> et
y code> est toujours défini en même temps, ou qu'ils commencent à
-1 code>. Voir ma réponse pour plus de détails.
On dirait que cela veut être encapsulé, qui supprimerait la complexité du site d'utilisation.
L'encapsulation doit fournir tous les comportements, y compris à partir de -1, -1 Code> et définir les deux
x code> et
y code> en même temps. Vous pouvez faire quelque chose comme ceci: p>
Pourquoi pas une classe personnalisée, quelque chose comme, surtout, car il s'agit d'une taille fixe.
class MyClass { public MyClass(int x, int y) { } public int X { get; set; } public int Y { get; set; } public int[] ToArray() { return new[] { X, Y }; } public List<int> ToList() { return ToArray().ToList(); } }
Les classes personnalisées sont bonnes. Mais je pense que cela serait juste un code supplémentaire qui doit être maintenu. Merci pour l'idée cependant. J'aime utiliser les getters and Setters, rend la vie gérable :)
struct pourrait fonctionner trop
L'approche 2 serait meilleure car l'approche 1 provoque une allocation de mémoire inutile (création de la nouvelle liste, et une matrice, etc.) P>
Cependant, le fait que votre liste n'a jamais eu que 2 articles qui me fait penser qu'une liste est la mauvaise classe à utiliser dans votre scénario. P>