Yes after I pressed the button I realized the error of my ways (re
reduce maintainability).  I partially agree with you about the
exposing of the internal nastyness,however that is a choice to be made
by the developer per use basis.  To not have that there is like saying
we dont offer you object oriented programming cause you will make
mistakes....well kinda (not meant to be a deeply religious argument
open for internet flaming).


On Jan 17, 11:53 am, "Henner Zeller" <> wrote:
> Hi,
> On Sat, Jan 17, 2009 at 9:30 AM, Chris <> 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
>   business_object->data().get_foobar().
> 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' .. ;)
> -h
> > 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 <> 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
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to