No uso patrones de diseño muy a menudo, además de una fábrica ocasional y MVC, y quiero comenzar a usarlos más.
Tengo a mano un caso concreto en el que me gustaría su opinión sobre el uso de patrones de diseño en este caso.
En mi aplicación, tengo que convertir objetos con bastante frecuencia en diferentes situaciones. Puede que tenga que convertir un POJO de Hibernate a un DTO, porque uso GWT y los POJO de Hibernate no son serializables y no se pueden enviar por la línea.
En otra situación, podría necesitar convertir objetos Java en SolrInputDocument para que indexe Solr.
Me gustaría saber si debo usar un patrón de diseño para esto. Parece que la "conversión de objetos" es una tarea genérica que podría manejarse de manera flexible / abstracta mediante un patrón, pero realmente no veo cómo.
Sin patrones, simplemente crearía una clase separada para cada tipo de conversión, por ejemplo CourseToSolrInputDocument (Course es una entidad de Hibernate en mi aplicación). O CourseToCourseDTO. Cada una de estas clases de conversión puede tener un único método estático llamado convert()que toma el objeto fuente como entrada y devuelve el objeto de salida.
Pero eso no es realmente un patrón, ¿verdad? Así que comencé con algo con genéricos y creé esta clase que implementa la interfaz del convertidor. Pero de alguna manera se siente tonto crear una interfaz genérica y realmente no veo la ventaja de poder felicitarme por el uso de genéricos.
public class CourseToSolrInputDocument implements Converter<Course, SolrInputDocument> {
@Override
public void convert(Course source, SolrInputDocument destination) {
//To change body of implemented methods use File | Settings | File Templates.
}
}Entonces, la verdadera pregunta aquí es: ¿existe un patrón que se aplique a la conversión de objetos genéricos y cuál sería su enfoque y cuáles son las ventajas de usar solo un enfoque de tipo clase por conversión?