Estoy tratando con un conjunto de objetos de mensaje, cada uno de los cuales tiene un identificador único que les corresponde. Cada mensaje se puede construir desde un Mapa, o desde un ByteBuffer (los mensajes son binarios, pero sabemos cómo transferir desde y hacia una representación binaria).Java: método de fábrica estático y declaraciones de cambio
La implementación actual para la construcción de estos mensajes es aproximadamente el siguiente:
public static Message fromMap(int uuid, Map<String, Object> fields) {
switch (uuid) {
case FIRST_MESSAGE_ID:
return new FirstMessage(fields);
.
.
.
default:
// Error
return null;
}
}
public static Message fromByteBuffer(int uuid, ByteBuffer buffer) {
switch (uuid) {
case FIRST_MESSAGE_ID:
return new FirstMessage(buffer);
.
.
.
default:
// Error
return null;
}
}
Ahora, Josh Bloch's Effective Java habla de Punto 1: Considere métodos de fábrica estáticas en lugar de constructores, y esto parece ser un lugar donde este patrón es útil (los clientes no tienen acceso directo a los constructores de los subtipos de mensajes, sino que pasan por este método). Pero no me gusta el hecho de que tengamos que recordar mantener dos instrucciones de cambio actualizadas (viola el principio DRY).
Agradecería cualquier idea sobre la mejor manera de lograr esto; no estamos almacenando objetos en caché (cada llamada a fromMap o fromByteBuffer devolverá un nuevo objeto), lo que niega algunos de los beneficios de utilizar un método de fábrica estático como este. Algo acerca de este código me parece erróneo, por lo que me encantaría escuchar las opiniones de la comunidad sobre si esta es una forma válida de construir nuevos objetos, o si no sería una mejor solución.
Si los objetos de fábrica se almacenan en un mapa y se recuperan con uuid, no es necesario cambiarlos. – rsp
yup, eso es lo que dije :-) Incluso agregué un enlace a tu respuesta :) – Fortega
Es una buena solución (así que +1 para eso) pero si el objetivo era deshacerte del doble cambio, podrías haber tenido en cuenta fuera de la lógica del interruptor a un método separado. (el mapa es básicamente un interruptor disfrazado) – wds