L'utilité de required
a été au cœur de nombreux débats et guerres incendiaires. De grands camps ont existé des deux côtés. Un camp aimait garantir qu'une valeur était présente et était prêt à vivre avec ses limites, mais l'autre camp se sentait required
dangereux ou inutile car il ne peut pas être ajouté ou supprimé en toute sécurité.
Permettez-moi d'expliquer davantage les raisons pour lesquelles les required
champs doivent être utilisés avec parcimonie. Si vous utilisez déjà un proto, vous ne pouvez pas ajouter un champ obligatoire car les anciennes applications ne fourniront pas ce champ et les applications en général ne gèrent pas bien l'échec. Vous pouvez vous assurer que toutes les anciennes applications sont mises à niveau en premier, mais il peut être facile de faire une erreur et cela n'aide pas si vous stockez les protos dans n'importe quel magasin de données (même de courte durée, comme memcached). Le même type de situation s'applique lors de la suppression d'un champ obligatoire.
De nombreux champs obligatoires étaient "évidemment" requis jusqu'à ce qu'ils ne l'étaient pas. Disons que vous avez un id
champ pour une Get
méthode. C'est évidemment nécessaire. Sauf que plus tard, vous devrez peut-être modifier l' id
int de chaîne en int, ou int32 en int64. Cela nécessite l'ajout d'un nouveau muchBetterId
champ, et maintenant vous vous retrouvez avec l'ancien id
champ qui doit être spécifié, mais est finalement complètement ignoré.
Lorsque ces deux problèmes sont combinés, le nombre de required
champs bénéfiques devient limité et les camps se demandent s'il a encore de la valeur. Les opposants required
n'étaient pas nécessairement contre l'idée, mais sa forme actuelle. Certains ont suggéré de développer une bibliothèque de validation plus expressive qui pourrait vérifier required
quelque chose de plus avancé name.length > 10
, tout en s'assurant d'avoir un meilleur modèle de défaillance.
Dans l'ensemble, Proto3 semble favoriser la simplicité et la required
suppression est plus simple. Mais peut-être plus convaincant, la suppression de required
sens pour proto3 lorsqu'elle est combinée avec d'autres fonctionnalités, comme la suppression de la présence de champ pour les primitives et la suppression des valeurs par défaut écrasantes.
Je ne suis pas un développeur de protobuf et je n'ai aucune autorité sur le sujet, mais j'espère toujours que l'explication sera utile.