Java Serialization with Protocol Buffer

Question

I want to use protobuff in a Java application to facilitate serialization and I have a question about this quote from the Google web site

Protocol Buffers and O-O Design Protocol buffer classes are basically dumb data holders (like structs in C++); they don't make good first class citizens in an object model. If you want to add richer behaviour to a generated class, the best way to do this is to wrap the generated protocol buffer class in an application-specific class. Wrapping protocol buffers is also a good idea if you don't have control over the design of the .proto file (if, say, you're reusing one from another project). In that case, you can use the wrapper class to craft an interface better suited to the unique environment of your application: hiding some data and methods, exposing convenience functions, etc. You should never add behaviour to the generated classes by inheriting from them. This will break internal mechanisms and is not good object-oriented practice anyway.

from: http://code.google.com/apis/protocolbuffers/docs/javatutorial.html

What does it mean when it says to wrap the created class?

Answer 1

Perspective 1

You write a .proto file and give it to protoc that generates the Builder code. They are suggesting not to add any methods to the generated code. If at all you want some custom behavior to be added to the generated code then WRITE YOUR OWN CLASS WRAPPING the generated code.

For e.g let us say the protoc generated class is MyMessageBuilder. And you wanted to add a method that can take XML input and spitout the protobuff specific message out. You would write a XmlToMyMessageBuilder as below. Here XmlToMyMessageBuilder, your class is wrapping the generated code and adding custom behavior fromXml().

public class XmlToMyMessageBuilder
{
    private final MyMessageBuilder protoBuilder;

    public MyMessage fromXml(byte[] input()
    {
        protoBuilder.setXXX();
    }
}

This is a general good programming principle.

Perspective 2

By providing a intermediary you can also DECOUPLE your code from the underlying serialization mechanism. This allows you to switch the serializer implementations (say you want to serialize a payload where all the data is in string format...where JSON seriazation with compression is a better alternative) with low impact. You could do something like this

public interface MySerializer
{
    boolean serialize(MyDomainObject input);
}

public PBBasedSerializer implements MySerializer
{
    private final MyMessageBuilder protoBuilder;
    ...
}

public JsonBasedSerializer implements MySerializer
{
    private final JSONSerializer jsonSerializer;
    ...
}

Answer 2

It means that you would implement your own class that contains a protocol buffer object as a private field.

Protocol buffer classes are generated from .proto files. These generated classes have all methods to directly manipulate the fields they contain. But they don't have methods that serve higher level operations than just modifying a field.

Your wrapper class can then provide a richer or more restricted interface to users of your API. As any modification of the protocol buffer needs to go through the wrapping object, you have full control about what operations you want to support.