¿Debo crear interfaces para objetos de transferencia de datos?

La respuesta general es no , porque nunca debe agregar código sin tener una razón específica y concreta, y no existe una razón general para dicha interfaz.

Dicho esto, a veces puede haber una buena razón. Pero en todos los casos que he visto, estas interfaces eran parciales, cubriendo solo una o unas pocas propiedades compartidas por varias clases que quería usar de forma polimórfica sin darles una superclase común. Los candidatos típicos son una propiedad Id para usar en algún tipo de registro o una propiedad Name para mostrar al usuario. Pero puede ser útil en cualquier caso en el que desee que un código maneje todo lo que tiene una X; simplemente cree una interfaz XSource que contenga los métodos getX (y, solo si es necesario, setX ).

¿Pero una interfaz separada para cada clase de modelo, que contiene todas las propiedades? No puedo imaginar una buena razón para hacer eso. Una mala razón sería un marco mal diseñado que lo requiera; La entidad EJB hizo exactamente eso, si recuerdo bien. Afortunadamente, fueron tan malos que nunca ganaron mucha tracción y están en desuso desde EJB 3.0

Sidenote: por favor, evite usar el término "objeto de valor" para describir los beans de Java que solo tienen elementos de obtención y configuración triviales; entra en conflicto con la definición más común de objeto de valor como algo sin identidad que generalmente es inmutable. Un término mejor sería DTO o clase de modelo, aunque en este último caso tenga en cuenta que modelos de dominio anémico se consideran antipattern.

Las interfaces definen un contrato entre las clases que implementan las interfaces y sus clientes. Se utilizan como un mecanismo de abstracción para que los clientes puedan manipular "las cosas que tienen un comportamiento determinado".

Entonces, la respuesta general a la pregunta "¿Debo crear y usar esta interfaz?" es: Sí, si puede asociar un concepto (uno único) que sea relevante para sus clientes.

Por ejemplo, Comparable es una buena interfaz, porque explica que las cosas se pueden comparar gracias a uno de sus métodos, y como cliente, estoy interesado en tratar con objetos comparables (por ejemplo, para clasificándolos). A contrario, CoolStuff no es una buena interfaz si admite que los objetos geniales no tienen un comportamiento específico (de hecho, puede imaginar un software en el que tratar con objetos geniales tenga sentido, porque tienen un comportamiento común como el método beCool ).

En su caso particular, creo que su interfaz es inútil. ¿Quién lo usará, cómo y cuándo? No puede crear una interfaz para cada uno de los valores mutables. Entonces pregúntese cuál es la propiedad relevante e interesante detrás de sus métodos.

Si lo que quieres es lidiar con objetos a los que se pueda acceder a todos sus valores mutables a través de un par de métodos, observa la noción de Java Bean y la forma en que puedes forzar a tus clases a adoptar sus convenciones.     

Como dijo Michael, no agregue una interfaz a menos que tenga una necesidad específica para ella.

Las pruebas son un ejemplo de una buena razón. Aunque prefiero usar colaboradores reales si son solo "objetos de valor" como los llama, para el verdadero aislamiento de prueba unitaria puede que necesite crear un objeto falso para la prueba, en cuyo caso una interfaz es muy útil.

Si desea que este objeto tenga algún tipo de validación de campos en el futuro, debe incluirlos en las etapas iniciales.

La creación de la interfaz está bien, pero NO de la forma en que funciona su ejemplo. Debería eliminar el setter de la interfaz, y estará bien:

interface ValueObject {
  String getName();
};

Esto permite muchas implementaciones diferentes de la misma, como el nombre se puede obtener de la base de datos ... Setter debería estar en una interfaz diferente.

La 'interfaz para el objeto de valor' es lo que estoy usando para llamar a un descriptor de acceso.

Experimenté diferentes políticas con respecto a las necesidades de los usuarios. Algunas personas abogan por lo más posible, otras prohiben luego reducir la cantidad de código para escribir.

Algunas razones para los usuarios de acceso (o uso de valor directo) son las siguientes:

• Los accesores permiten cambiar posteriormente la forma en que se almacena el valor
• Accessors permite agregar el registro de acceso cuando desea depurar su software (al agregar una llamada de registro en un solo método, captura cada cambio de valor)
• Los accesores están más en línea con la programación de objetos, cada variable está encapsulada por métodos
• Accessors reduce la expresividad del código (más SLOC para el mismo resultado)
• Accessors toma algunos CPU

Personalmente abogo por reducir la cantidad de accesores y usarlos cuando esperas que el setter (setName) se convierta en algo más que una simple afectación más adelante.

Este tipo de objeto de valor es un nivel bastante bajo. Sugeriría empujarlo en una de dos direcciones: (1) hacer que el objeto de valor sea inmutable, es decir, como un valor real , o, (2) elevar la mutabilidad a un nivel superior orientado al dominio función empresarial, lo que significa que debemos exponer las interfaces en términos de unidades de funcionalidad relevantes para el dominio.