I believe that extending one of the generated types would be problematic
from a maintainability standpoint, and may introduce unnecessary
limitations with regards to using and extending the business classes.
Have you considered associating behaviours with the data instances using
a wrapper-style approach?  

The business classes could wrap instances of the generated data
structure classes, accessing and manipulating their properties as
needed.  Serialization of these objects could amount to serializing
their data, perhaps wrapped in a message which includes the business
object specifier so the correct type could be determined dynamically
when parsing.

If the application is such that extending the generated message types
could have made sense, then it may make sense to view the wrapper based
solution in terms of object state.

# Marshalling
state = business_object.get_state()
bytes = state.SerializeToString()

# Unmarshalling

On Fri, 2009-01-16 at 23:14 -0800, Chris wrote:
> Hi, sorry if this is a dumb question.  I have class A which I want to
> serialize but equally want to add logic to it (which I cant today
> because its generated). I was wondering if there was:
> - An ability that if I created class of type B that extends A, where
> no member variables of B would be serialized.
> - Then provide the correct handling during serialization.
> Basically B contains my business logic, A contains all the serialized
> fields.
> This technique is not unknown to a similar problem of object
> relational mapping.
> Currently it seems a little messy, we are either copying fields to and
> from the serialized form into a richer object or using lots of
> delegation, neither of which is that clean.
> Best
> ChRiS
> > 

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to