Google Protobuf: Excellent idea, well executed but only if.....
A proposal to add interface decoration to Protobuf generated messages.
Background
Google Protobuf is a language that defines how one encodes messages on a transport.Like everything Google - it is well thought out, not over designed and intelligently implemented. It is target language agnostic, efficient and allows for managed upgradeability.
Except:
The .proto message compiler (protoc) only creates rich (final) Message classes. These contain the immutable messages and access to builders for creating new messages.
Java Interfaces
Perhaps the best language feature of Java (there are many more...) is the Interface. It is a traditional implementation-free definition of the contract that an implementing object must provide.It has a number of advantages including:
- Using an interface means that you can change the implementation but maintain the contracted functionality;
- You can write collaborators that work on objects that implement the interface without any other knowledge or dependencies on the implementation;
- When testing classes that use the interface you can stub easily stub or mock out the interfaced object;
- And many more.
Using protobuf generated message classes in the real world
The only problem is that a protobuf Message does not implement a simple interface - typically when you are receiving messages over a transport - you want to pass the messages on to handlers that know nothing about how they were encoded over the transport - indeed you might be handling the same message from different sources. OO would suggest that you're handlers would only require objects that allow access to he properties that they require to do their work. As the Protobuf Generated Message class has no means of attaching an interface one has to take one of two routes:- Create a new Object from the Message (probably using a factory) that implements your interface; or
- Create a delegate that when you give it an object it extracts the relevant part.
Proposal - decorating Generated Messages with Interfaces
My suggestion is to allow one to write an interface to encapsulate the properties you require from any message you will be processing and then decorate the Generated Message with that interface.For instance, if we have a message in spotrate.proto:
message SpotRate {Then if our message consumer was only interested in the currency pair andrate we would create an interface in ISpotRate.java:
required uint64 timestamp = 1;
required string currencyPair = 2;
required double rate = 3;
required string trader = 4;
// ... and so on
}
public interface ISpotRate {
String getCurrencyPair();
double getRate();
}
[HERE - show example new syntax and usage]
