Estamos presentando búferes de protocolo como el nuevo transporte para algunos servicios RPC de back-end. Debido a que existe resistencia a la transferencia manual de datos entre diferentes formas de objetos similares, puedo evitar que las instancias de Protocol Buffer pasen por la pila un poco más allá de la interfaz del servidor RPC.Usando el búfer de protocolo como objeto de datos general?
¿Es esto algo que debo tratar de evitar? ¿Es seguro tratar un objeto de búfer de protocolo como un soporte de datos simple, con la agradable conveniencia de que se puede transformar de forma rápida y eficiente en binario?
La otra razón por la que veo que es una buena forma de generar objetos de datos es la noción de campos obligatorios/opcionales y la interfaz del constructor generada automáticamente.
Creo que el hecho de que sean inmutables realmente ayuda, no duele, cuando se trata de usar memorias intermedias de protocolos como esta. Son objetos de valor inmutables como String. –
Ciertamente ayuda en algunos casos, cuando puede escribir código en un estilo funcional. En parte depende del problema y en parte de los desarrolladores :) –
Immutable realmente ayuda en algunos casos, por razones desconocidas existen algunas construcciones públicas con una docena de parámetros más o menos, todos asignados a los campos finales. Un constructor es genial pero tedioso y repetitivo para escribir cada vez. También es complicado obtener la lógica de derecho requerido frente a derecho opcional, de modo que el método build() explote si se han omitido los campos obligatorios. –