Thank you Kenton and Jason for the advice.  I have a couple more
questions as I move forward with PB implementations.

In the documentation it states that PBs don't make good first class
citizens in an OO domain model and the suggestion is of course to wrap
the PB.  Through some other posts it is quite evident that you do not
want people subclassing or using 'extends' in Java on PBs.  However,
in process of looking at wrapping classes it is quite clear the
Message and Builder interfaces will be common across every PB I
create, but for each PB there will be a uniqe set of setters, getters,
and has functions for my protocol member fields.  Am I going to get
into trouble creating the following type of abstract class using
generics:


public abstract class MyAbstractMessage<T extends GeneratedMessage, B
extends GeneratedMessage.Builder<?>> {


        protected T message;
        protected B builder;


    // This is implemented here only to work around an apparent bug in
the
    // Java compiler and/or build system.  See bug #1898463.  The mere
presence
    // of this dummy clone() implementation makes it go away.
    @Override
    public B clone() {
      throw new UnsupportedOperationException(
          "This is supposed to be overridden by subclasses.");
    }
        /**
         * see {...@link GeneratedMessage#newBuilderForType()}...@link
MessageLite#newBuilderForType()}
         * @param obj
         * @return
         */
        @SuppressWarnings("unchecked")
        public final B newBuilder() {
                return (B) message.newBuilderForType();
        }

        /**
         * see {...@link GeneratedMessage.Builder#build()} {...@link
MessageLite.Builder#build()}
         * @return
         */
        @SuppressWarnings("unchecked")
        public final T build() {
                message = (T) builder.build();
                builder = null;
                return message;
        }

        // ... wrap all the Message and Builder interface methods  ...

}

Then for each PB I create I would wrap them in an implementation of
this abstract class and add my additional setters and getters, hide
what I want about builder creation or message object creation and
implement interfaces as necessary.

Is this approach heading down a path that will create chaos in my life
going forward as migrate numerous protocols to the PB implementation?

One final question, I have realized enumeration changes may be
particular difficult to adapt to with compatibility issues.  Can you
point to any strategies here?

Thank you for all the input and advice!

On Sep 21, 3:38 pm, Kenton Varda <ken...@google.com> wrote:
> On Wed, Sep 15, 2010 at 6:03 AM, users .... <moofis...@gmail.com> wrote:
> > I am implementing PB to provide an external interface and API to a
> > developing system.  I know the interface will change and the extension/
> > backwards compatibility is a major benefit.  When designing the .proto
> > files should I, for pure flexibility, make everything optional or
> > repeated fields? If I do this I can then write separate Validate
> > functions for each implementation revision.  I can see an opportunity
> > to automate the validate function creation with the code generating
> > capabilities.  This will remove the burden of "required is forever"
> > but will it impact performance or have other negative effects that I
> > can not see?  Is this a good practice for flexible implementations or
> > are there better patterns?
>
> This is exactly what I usually recommend to people, and do in my own code.
>  There are no significant performance effects (if anything, performance will
> be better because there are fewer checks to perform when parsing).  But as
> Jason says, opinions vary.
>
>
>
>
>
> > Thanks
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.c­om>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.- Hide quoted text -
>
> - Show quoted text -

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to