On Sat, Jan 17, 2009 at 9:30 AM, Chris <chrisjcoll...@gmail.com> wrote:
> Thanks Steve and Alek.  As I mentioned wrappers delegating access to a
> containing class and simple copy to from a business class is what we
> do today and its a mess, its error prone and its totally manual, am I
> missing something?  Every new attribute needs to either have a few
> lines more added to the business class to get and set its values.

Typically, a business class should not expose all the internal state
(i.e. the attributes of the underlying data) in the first place. You
should be very specific which attributes you expose.

Anyway, having said that, you might consider just returning a
reference or pointer to the protocol buffer kept in the business class
in case you _really_ have to access the internal data
This way you don't have to modify anything in case you add fields to
the data. However, this way you always expose all properties of the
internal data which is a bad idea - but again, this would have
happened with the inheritance approach as well.
On advantage as well is that the access code looks sufficiently ugly
that users will avoid using internal data fields directly :)

> In
> a prior job I did use a system where persisted classes were generated
> as *Base classes where you were expected to implement the * extending
> *Base.  This worked very well and reduced maintainability.

You said the right thing here, but I guess you meant to say 'reduced
maintenance' .. ;)


> I can of
> course imagine that for languages that are not OO it would prove to be
> a challenge (yes I dont use Python).
> Thanks
> C
> On Jan 17, 12:20 am, Alek Storm <alek.st...@gmail.com> wrote:
>> I agree with Shane.  Wrapping the data is a great way to separate the
>> business logic from the data.  Actually, if you're using Python,
>> you're not allowed to subclass generated message types (though there's
>> no 'sealed' modifier) - it screws with the metaclass machinery.
>> Cheers,
>> Alek
> >

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