Question

Protocol Buffer documentation warns that …

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.

source:Protocol Buffer Basics

My two part question is:

1. What internal mechanisms could this break?
2. In what way is this not good a good OO practice anyway?

Answer 1

1. “What goes wrong” is going to be very implementation specific. If you cited a specific implementation, it might be possible to answer, but in the more general sense: this is not a supported scenario, and implementations are not required to work correctly or at all if you subclass. This is an undefined behaviour, with all that implies. Further, protocol buffers does not support inheritance, because not all target platforms can support it. Key thoughts:

   • there may be code that checks the incoming object against a list of expected types – if yours isn’t there, it could fail
   • it won’t handle any fields etc that you add
   • the whole idea of a serializer is to robustly give back what you serialized; if you serialize a SomeDerivedClass, there’s no way the serializer can give you that back
   • the entire point of a library like this is to hide away gory implementation details; you are not expected to be messing with any of the implementation (polymorphism must be designed for)

2. As an OO concern; this is not your type; it is a DTO that is designed to serve a specific purpose. Common usage might be to map from the DTO to/from your domain model, which can be more complex, or possibly to encapsulate the DTO if that is useful (perhaps as a façade).