Angenommen, ich habe zwei Proto Puffertypen:Kopieren Felder über Objekte verschiedener Art in gRPC
message MessageType1 {
SomeType1 field1 = 1;
SomeType2 field2 = 2;
SomeType3 field3 = 3;
}
message MessageType2 {
SomeType1 field1 = 1;
SomeType2 field2 = 2;
SomeType4 field4 = 3;
}
Dann in Java Ich möchte in der Lage sein, ein zu verwenden Objekt als Vorlage zu einem anderen:
MessageType1 message1 = ...;
MessageType2 message2 = MessageType2.newBuilder()
.usingTemplate(message1) // sets field1 & field2 only
.setField4(someValue)
.build()
statt
MessageType1 message1 = ...;
MessageType2 message2 = MessageType2.newBuilder()
.setField1(message1.getField1())
.setField2(message1.getField2())
.setField4(someValue)
.build()
Warum ich das brauchen? Mein gRPC-Dienst ist so konzipiert, dass er eingehende Daten eines Typs (message1
) entgegennimmt, der fast identisch mit einer anderen Nachricht eines anderen Typs (message2
) ist - die gesendet werden muss. Die Anzahl der identischen Felder ist riesig und der Code ist banal. Die manuelle Lösung hat auch den Nachteil eines Fehlschlags, wenn ein neues Feld hinzugefügt wird.
Es gibt eine Template-Methode (object.newBuilder(template)
), die das Templating-Objekt des gleichen Typs erlaubt, aber wie wäre es mit Templating zwischen verschiedenen Typen?
Ich könnte natürlich ein kleines Reflexionsprogramm schreiben, das alle Mitglieder (Methoden?) Inspiziert und manuell Daten kopiert, aber generierter Code sieht entmutigend und hässlich für diese Art von Quest aus.
Gibt es einen guten Ansatz, um dies anzugehen?
Das klingt wie Sie sollten eine gemeinsame Unternachricht aus beiden Nachrichtentypen für ihre Kreuzung gezogen haben. (Oder, machen Sie es nur einen Nachrichtentyp und die eingehenden und ausgehenden Versionen haben unterschiedliche Teilmengen ihrer Felder in Gebrauch.) –
Danke für Ihren Vorschlag @LouisWasserman! Das Extrahieren eines allgemeinen Typs ist eine Option, aber gebräuchliche Typen fügen boilerplate hinzu und wären in meiner Situation nicht geeignet, da src/dest aus verschiedenen Paketen stammt und verschiedene, nicht gemeinsam nutzbare Kontexte hat. Ich schrieb schließlich mein eigenes Dienstprogramm; Ich hoffe, ich habe keine Eckfälle verpasst (z. B. was passiert, wenn das Zielfeld innerhalb von "oneof" liegt und das Quellfeld nicht?). Ich denke, ich muss nur warten und sehen, wie ich vorankomme. – mindas