The rationale is discussed in https://github.com/grpc/grpc/issues/5371
For server side, Mocking/DI works fine for abstract base class. For client side, you should never mock the stubs, because a mock/fake stub is totally inconsistent with how the gRPC library actually works. For testing, a real stub constructed with an InProcessChannelBuilder is recommended. (testing examples: https://github.com/grpc/grpc-java/tree/master/examples/src/test/java/io/grpc/examples) On Wednesday, February 15, 2017 at 12:56:23 PM UTC-8, Ryan Michela wrote: > > When protoc generates java stubs, it doesn't create interfaces for stubs > or services. Instead, the blocking/async stubs are final classes and the > service is an abstract base class. Interfaces would make mocking, DI, and > utility classes easier to implement. > > Is the absence of generated interfaces an explicit design decision, and if > so, what is the rationale? > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/32ae7b85-656e-4c23-b7bb-ab8d52363fb0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
