[JAVA] Comment gérer facultatif dans les tampons de protocole (proto3)

Les tampons de protocole ont été supprimés de «obligatoire» et «facultatif» dans proto3. En ce qui concerne le contexte de la suppression, voir @qsona Entrée pour un résumé facile à comprendre. Je vous remercie.

Le problème est que dans proto3, chaque champ a une valeur par défaut, donc le champ avec la valeur par défaut est du côté de l'utilisateur.

1. «Une valeur similaire à la valeur par défaut intentionnellement définie»
2. Valeur par défaut non définie car elle n'existe pas Cela signifie que vous ne pouvez pas non plus juger.

En d'autres termes, comment exprimer une valeur facultative.

Comment exprimer en option

Il existe plusieurs options, mais la réponse de Stack Overflow est utile. Sera.

1. Dans un champ distinct, exprimer explicitement la présence ou l'absence

schema.proto

message User {
  int32 id = 1;
  bool has_name = 2; //Indique la présence ou l'absence de nom
  string name = 3;   //Valeur actuelle
}

Example(Java)

User user1 = User.newBuilder()
		.setHasName(true)
		.setName("Tom")
		.build();

User user2 = User.newBuilder()
		.setHasName(false) //La valeur par défaut est false, vous n'avez donc pas réellement besoin d'un ensemble
		.build();

user1.getHasName(); // true
user1.getName();    // "Tom"

user2.getHasName(); // false
user2.getName();    // ""

2. Utilisez l'un des

schema.proto

message User {
  int32 id = 1;
  oneof name_optional {
    string name = 2; //Enveloppez la valeur de traitement avec l'un des
  }
}

Example(Java)

User user1 = User.newBuilder()
		.setName("Tom")
		.build();
User user2 = User.newBuilder()
		.build();

user1.getNameOptionalCase(); // User.NameOptionalCase.NAME
user1.getName();             // "Tom"

user2.getNameOptionalCase(); // User.NameOptionalCase.NAMEOPTIONAL_NOT_SET
user2.getName();             // ""

3. Utilisez google / protobuf / wrappers.proto

schema.proto

message User {
  int32 id = 1;
  google.protobuf.StringValue name = 2;
}

Example(Java)

User user1 = User.newBuilder()
		.setName(StringValue.newBuilder().setValue("Tom").build())
		.build();
User user2 = User.newBuilder()
		.build();

user1.hasName();            // true
user1.getName().getValue(); // "Tom"

user2.hasName();            // false
user2.getName().getValue(); // ""

Considération

La première chose que nous avons tous en commun est que quelle que soit l'option que vous choisissez, vous ne pouvez pas la forcer à être une valeur facultative. * 1 Par conséquent, pour toute option, il est nécessaire d'effectuer de manière procédurale «vérifier l'existence» → «traiter la valeur».

En 1, la notation est très simple, mais le compilateur ne peut garantir la relation entre les deux champs, et il est nécessaire de la supporter avec des commentaires.

Par rapport à 1, 2 a l'avantage de pouvoir exprimer la présence ou l'absence de champs au niveau du compilateur, mais c'est un usage un peu étrange de l'un des domaines où plusieurs champs sont supposés.

3 est intuitif et facile à utiliser lorsqu'il s'agit de valeurs optionnelles, mais il présente également certains inconvénients.

• Légèrement redondant, comme avoir besoin d'un générateur pour les wrappers ou appeler getValue () pour récupérer des valeurs
• Si vous souhaitez rendre une valeur non primitive facultative, vous devez l'utiliser avec 1 ou 2, et il existe deux façons d'exprimer optionnel, qui ne peuvent pas être unifiées.

Exemple:

schema.proto

message User {
  int32 id = 1;
  Fullname fullname = 2;
}

message Fullname {
  string first_name = 1;
  string last_name = 2;
}

Par exemple, dans un tel cas, le wrapper n'est fourni qu'avec les types suivants, il ne peut donc pas être utilisé si vous souhaitez rendre chaque nom complet facultatif.

DoubleValue
FloatValue
Int64Value
UInt64Value
Int32Value
UInt32Value
BoolValue
StringValue
BytesValue

Par conséquent, si vous souhaitez unifier des expressions facultatives, il est facile de comprendre unifier avec 1 ou 2.

• 1: Diverses implémentations en fonction de la langue, mais celles qui appliquent des possibilités inexistantes telles que Peut-être, Option, Facultatif et Sécurité nulle

Résumé

Protocol Buffers est un langage de schéma avec des spécifications compactes et se caractérise par de faibles coûts d'apprentissage et une bonne lisibilité. Cependant, pour cette raison, certaines expressions communes à d'autres ont été supprimées, et je pense que davantage d'expressions peuvent être créées en les utilisant tout en les couvrant en temps opportun.