java - reales - libro de android studio en español pdf
Clase de Utilidad de Java vs. Servicio (5)
¿Cuál es la diferencia en Java entre una clase de utilidad (una clase con métodos estáticos) y una clase de servicio (una clase con métodos públicos que proporciona un "servicio"). Por ejemplo, se puede argumentar que un objeto criptográfico (que proporciona métodos para cifrar, descifrar, calcular o obtener un valor de sal) es un proveedor de servicios, pero muchos agrupan esta funcionalidad en una clase de utilidad con métodos estáticos, como CryptoUtil.encrypt (... .). Estoy tratando de descubrir qué camino sigue mejor "diseño". ¿Pensamientos?
Creo que no hay reglas duras y rápidas.
Normalmente utilizo métodos estáticos para la funcionalidad que requiere pocos parámetros, y se puede lograr en una sola llamada a un método. Ejemplo:
- calcular un valor hash para una cadena
- convertir una fecha en representación estándar
Si una funcionalidad requiere muchos parámetros, y si se están creando varios resultados relacionados, entonces es más práctico tener un classe que pueda aceptar los parámetros compartidos en su constructor, con varios métodos que realizan la acción real.
Ejemplo típico: una conexión de base de datos, que primero se conecta, luego se usa para hacer una consulta, luego se usa para obtener el resultado ...
La diferencia es que las clases de servicio pueden tener estado. Y por estado me refiero al estado conversacional. Considere un sistema de ordenamiento nocional.
interface OrderSystem {
void login(String username, String password);
List<Item> search(String criteria);
void order(Item item);
void order(Item item, int quantity);
void update(Item item, int quantity);
void remove(Item item);
void checkout();
Map<Item, Integer> getCart();
void logout();
}
Tal cosa podría hacerse con beans de sesión con estado (como un ejemplo), aunque en ese caso la autenticación probablemente se cubriría con mecanismos EJB más tradicionales.
El punto aquí es que hay un estado conversacional en el sentido de que los resultados de una llamada afectan las llamadas subsiguientes. Puede ver los métodos estáticos como un conjunto de servicios simples sin estado que se ejecutan localmente.
Un servicio tiene un significado mucho más amplio que incluye, pero no se limita a, ser:
- con estado;
- remoto; y
- implementación dependiente (es decir, a través de una interfaz).
La mejor práctica, creo, es simplemente usar métodos estáticos como métodos de conveniencia (especialmente dada la falta de métodos de extensión de Java). Los servicios son mucho más ricos que eso.
No puede anular el método estático, que puede ser un gran problema en caso de que desee implementar su servicio de dos maneras diferentes y cambiar entre ellos. Por esta razón, limitaría el uso de clases de utilidad estática a cosas simples que "nunca" (con un valor suficientemente largo de "nunca" :)) deben realizarse de más de una manera.
Respondí esta pregunta aquí en algún lugar anteriormente, pero lo que encontré fue que era muy fácil cambiar el comportamiento de un servicio para refactorizarlo en servicios múltiples, donde se necesita un refactor bastante significativo si usa una clase estática.
Si esa es la única diferencia (y creo que lo es), entonces no tiene sentido usar clases estáticas.
Cada vez que alguien dice "Nunca habrá más de 1 de estos", codifique n de ellos.
Se pueden obtener diferentes comportamientos utilizando diferentes objetos de servicio. Los métodos estáticos en una clase de utilidad no se pueden intercambiar. Esto es extremadamente útil para probar, cambiar implementaciones y otros propósitos.
Por ejemplo, menciona un CryptoUtil con un método de CryptoUtil . Sería extremadamente útil tener diferentes objetos que podrían soportar diferentes estrategias de cifrado, diferentes destinatarios de mensajes, etc.