juste curieux, existe-t-il un moyen d'avoir un getter pour une variable constante? J'ai une sorte de numéro de version interne pour vous assurer que deux versions d'une bibliothèque parlent toujours la même langue, mais j'aimerais que le programmeur soit capable de vérifier la version qu'ils utilisent. En ce moment, j'utilise: mais je préférerais le faire avec juste le const s'il y a un moyen.
4 Réponses :
juste faire: Ceci fournira un getter public comme un const ne peut pas avoir un seigter.
Cela peut sembler idiot, mais lorsque j'utilise Get et défini pour les variables, je reçois une icône différente de l'intellensense que lorsque j'ai une variable publiquement exposée. Toutes mes autres variables exposées utilisent des getters and Setters (certains privés) et je voulais être cohérent car c'est une bibliothèque
Ce n'est pas la même chose qu'une propriété avec un getter: si vous mettez à jour la bibliothèque, vous devrez également recompiler le programme.
@Paolotedesco Pourquoi auriez-vous besoin de recompiler le programme? La seule raison pour laquelle le programmeur peut afficher le numéro de version est dû au fait que la bibliothèque, qui l'utilise dans le cadre d'une enveloppe de prise, refusera de parler à une autre instance de la bibliothèque où le protocole pourrait être ancien / nouveau. Au lieu de simplement dire «ils ne correspondent pas, dommage que le programmeur puisse obtenir la version, même s'ils ne peuvent rien faire quelque chose avec elle. J'essayais de ne pas être énigmatique.
Vous devez garder à l'esprit la raison de l'existence de getters / setters. Il est de contrôler l'accès à une variable encapsulée, spécifiquement pour contrôler la manière dont une variable est modifiée et qui peut le changer. Étant donné qu'un const n'est défini qu'une seule fois et reste en lecture seule au moment de l'exécution, il n'y a aucune raison de créer une propriété pour cela. La définition de la constante au public est totalement acceptable car ce n'est pas une variable privée qui doit être protégée.
Si vous ... Voulez-vous vraiment faire une propriété alors définissez-la comme une propriété lisonly, sautez entièrement le setter: P>
public const Int16 ProtocolVersion = 1
Je sais que c'est un peu stupide, j'essayais juste d'être cohérent avec ma bibliothèque
@cost i fait effectivement cela :) Il suffit de faire des propriétés publiques et des constantes ont le même style de codage et l'IntelliSense le montrera de la même manière. Dans certains cas, il est en fait utile de pouvoir distinguer les constantes de propriétés car vous savez une constante ne peut pas changer, mais une propriété réadonnée ne vous indique rien de la manière dont la variable sous-jacente est traitée à l'intérieur de la classe.
Un point supplémentaire: il n'y a aucun avantage à utiliser int16 . Utilisez int , int32 ou peut-être chaîne .
@HENKHOLTERMAN J'utilise int16 car la seule utilisation du numéro de version doit être envoyée sur une prise dans le cadre d'une poignée de main. Je n'ai vu aucun besoin d'envoyer 4 octets quand 2 serait bien plus que suffisant
@cost: Si vous devez envoyer un million de versions, il s'agit d'un point valide.
@HENKHOLTERMAN faisant juste ma part pour garder Internet gratuitement pour regarder Netflix et ce genre de chose
@cost: TCP n'envoie pas d'octets, il envoie des paquets. Votre version sera dans un bus avec beaucoup de sièges vides.
@Henkholesmanman et la version ne sont pas la seule chose qui soit envoyée dans la poignée de main. Quoi qu'il en soit, les paquets TCP ne sont pas une taille fixe. L'utilisation d'un Int 32 bits entraînerait toujours un paquet deux octets plus grande. Et d'ailleurs, quel préjudice est un intégré 16 bits en plus de souffrir de ne pas être aligné en mémoire
Les constantes ne peuvent pas être réaffectées, c'est pourquoi elles sont appelées constantes, il suffit donc de faire protocol_version public
Puis appelez-le protocolversion
Vous pouvez déclarer une propriété avec seulement un accesseur d'obtention (sans même déclarer l'accesseur défini, pas même privé): Ce n'est pas la même chose que la définition d'une constante uniquement: la constante Serait résolu à la compilation, donc si vous mettez à jour la bibliothèque sans recompiler le programme dépendant, le programme verrait toujours la valeur «ancienne». Considérez cet exemple: P> public static readonly Int16 protocol_version = 1;
C'est un point de goo, mais si quelque chose n'est pas une constante, alors ne faites pas un champ const en premier lieu.
@svick: Voyant comment la question a été formulée ("Je préférerais le faire avec juste le const") Je pensais que la distinction n'était peut-être pas claire pour lui.
C'est un bon point, je ne savais pas que les constantes travaillaient comme ça
Mais cela ne signifie-t-il pas que le getter est une bonne idée ici? Cela évite le problème du programme en pensant qu'il utilise un protocole plus ancien si la bibliothèque est réellement mise à jour. Comme Svick l'a souligné, je pouvais aussi facilement utiliser une variable non constante. Je n'ai utilisé que Const comme un rappel pour moi-même qu'il ne devrait jamais changer de manière programmatique
@cost: Vous pouvez alors utiliser une variable statique au lieu d'un const . Avec cela, vous éviterez les problèmes de la constance et la variable ne sera pas modifiable une fois initialisée.
Pour une raison quelconque, je pensais que Readonly n'était que l'équivalent VB de Const. Je suis curieux cependant, quelle est la différence fonctionnelle entre l'utilisation de la constante avec un getter (qui renvoie toujours la valeur correcte même avec seulement la recompilation de la bibliothèque) et le réadonly? Je vais le changer en lecture seule, mais je me demande juste
@cost: Regardez à nouveau l'exemple et essayez de réfléchir à la variable Const en tant que remplacement de texte au moment de la compilation ... de l'autre côté, la variable statique est toujours résolue au moment de l'exécution et Readonly applique uniquement qu'elle ne peut pas être modifiée après l'initialisation. J'espère que c'est clair ...
Je suis sûr que ce n'est pas ce que vous utilisez actuellement, car votre code ne compilera pas. En outre, quelque chose comme une version de protocole ne convient pas à un champ
const , car il n'est pas réellement constant - cela peut changer à l'avenir.@svick ah Oui, mon code ne peut pas y avoir défini, je devrais changer cela dans la réponse. C'était juste ma première pensée avant d'essayer de le compiler