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;
    ...
}