gRPC java: what is the best practice to overcome the setter challenge

[Vahab Jabrayilov]

Hi,

I have a following problem. I have message types defined in proto file and auto generated classes for them. Since, they don't have any setters associated with them I cannot use those classes in my main logic; hence I keep my version of custom implementation for main logic and use gRPC generated one for communication;

My question is "Is there any way to overcome having redundant classes ? How can I use the gRPC generated ones in my implementation such that I will be able to mutate them?"

Best,

Vahab

[Eric Anderson]

On Thu, Jul 7, 2022 at 5:30 AM Vahab Jabrayilov <jabrayil...@gmail.com> wrote:

Since, they don't have any setters associated with them I cannot use those classes in my main logic;

"Can't" is a bit strong. You could use the immutable objects in your logic, but I'd agree that produces a very different code structure. Immutable objects can have nice benefits when multi-threading.

hence I keep my version of custom implementation for main logic and use gRPC generated one for communication;

That is a common approach, but for the different reason of allowing your application internals to be a bit different from the messages used for communication. For example, if you want to add a "processed" bit to a message as part of a (theoretical) optimization, then you'd have to expose that to your users with your current design.

My question is "Is there any way to overcome having redundant classes ? How can I use the gRPC generated ones in my implementation such that I will be able to mutate them?"

You can use the builders as mutable objects, but only briefly. I think once you build a message (a copy) to use with gRPC it takes another copy to make its children mutable again. I think people just use the immutable objects or make their own classes.

[Vahab Jabrayilov]

Thanks a lot Eric for your detailed answer,

Best