privada - que es static en java
¿Las interfaces son un sustituto válido para las clases de utilidad en Java 8? (4)
Debe usar la interfaz solo si espera que alguien lo implemente. Por ejemplo, la interfaz java.util.stream.Stream tiene una serie de métodos estáticos que podrían ubicarse en algunas clases Streams o StreamUtils anteriores a Java 8. Sin embargo, es una interfaz válida que también tiene métodos no estáticos y puede implementarse. java.util.Comparable es otro ejemplo: todos los métodos estáticos solo admiten la interfaz. No puede prohibir a los usuarios que implementen su interfaz pública, pero para la clase de utilidad puede prohibirles crear una instancia. Por lo tanto, para la claridad del código sugiero no usar interfaces a menos que estén destinadas a ser implementadas.
Una nota con respecto a @ saka1029 respuesta. Si bien es cierto que no puede definir métodos y constantes privados de ayuda en la misma interfaz, no es un problema crear una clase privada de paquete en el mismo paquete como MyInterfaceHelper que tendrá todas las cosas necesarias relacionadas con la implementación. En general, las clases privadas de paquete son buenas para ocultar los detalles de su implementación del mundo exterior.
Esta pregunta ya tiene una respuesta aquí:
Durante la última década, he estado usando el patrón a continuación para mis clases de utilidad de Java. La clase contiene solo campos y métodos estáticos, se declara final por lo que no se puede extender, y tiene un constructor private por lo que no se puede crear una instancia.
public final class SomeUtilityClass {
public static final String SOME_CONSTANT = "Some constant";
private SomeUtilityClass() {}
public static Object someUtilityMethod(Object someParameter) {
/* ... */
return null;
}
}
Ahora, con la introducción de métodos estáticos en las interfaces en Java 8, últimamente me encuentro utilizando un patrón de interfaz de utilidad:
public interface SomeUtilityInterface {
String SOME_CONSTANT = "Some constant";
static Object someUtilityMethod(Object someParameter) {
/* ... */
return null;
}
}
Esto me permite deshacerme del constructor y muchas palabras clave ( public , static , final ) que están implícitas en las interfaces.
¿Hay algún inconveniente en este enfoque? ¿Hay algún beneficio al usar una clase de utilidad sobre una interfaz de utilidad?
No deberías usar la interfaz. Las interfaces no pueden tener constantes privadas e inicializadores estáticos.
public class Utility {
private Utility() {}
public static final Map<String, Integer> MAP_CONSTANT;
static {
Map<String, Integer> map = new HashMap<>();
map.put("zero", 0);
map.put("one", 1);
map.put("three", 3);
MAP_CONSTANT = Collections.unmodifiableMap(map);
}
private static String PRIVATE_CONSTANT = "Hello, ";
public static String hello(String name) {
return PRIVATE_CONSTANT + name;
}
｝
Partiendo de la base de que la persona que acuñó el patrón de la Interfaz Constante es un antipatrón, diría que aunque no pretenda que los clientes implementen la interfaz, aún es posible, posiblemente más fácil, y no debería permitirse :
Las API deben ser fáciles de usar y difíciles de usar. Debería ser fácil hacer cosas simples; posible hacer cosas complejas; e imposible, o al menos difícil, hacer cosas incorrectas.
Aunque como se menciona a continuación, realmente depende de la audiencia objetivo
Muchos patrones de diseños fáciles de usar reciben una gran cantidad de críticas (Patrón de contexto, patrón de Singleton, patrón de interfaz constante). Diablos, incluso los principios de diseño, como la ley del demeter, son criticados por ser demasiado prolijo.
Odiaría decirlo, pero este tipo de decisiones se basan en opiniones. Aunque el patrón de contexto se ve como un antipatrón, es evidente en los marcos convencionales como Spring y Android SDK . Se reduce al medio ambiente, así como a la audiencia objetivo.
El principal inconveniente que puedo encontrar se muestra como el tercer listado en "desventajas" en la wiki de la Interfaz constante :
Si se requiere compatibilidad de código binario en versiones futuras, la interfaz de constantes debe permanecer para siempre como una interfaz (no se puede convertir en una clase), aunque no se haya utilizado como interfaz en el sentido convencional.
Si alguna vez figura "Oye, esto en realidad no es un contrato y quiero aplicar un diseño más sólido", no podrás cambiarlo. Pero como he dicho, depende de usted; tal vez no te importe cambiarlo en el futuro.
Además de eso, la claridad del código mencionada por @TagirValeev. Las interfaces tienen la intención de ser implementadas; Si no quiere que alguien implemente la API que está suministrando, no la implemente. Pero creo que esto gira en torno a la declaración de "público objetivo". No voy a mentir, estoy contigo en la base menos detallada, pero depende de para quién es mi código; no querría usar una interfaz constante para el código que pueda ser revisado.
Pienso que puede funcionar. Creo que la variable SOME_CONSTANT se establece de forma predeterminada como estática final en su SomeUtilityInterface, aunque usted no lo dijo explícitamente. Entonces, funcionaría como una utilidad, pero ¿no tendrías algunos problemas de mutabilidad que no tendrías con una clase regular con todas las variables miembro que requieren ser definitivas? Mientras no sea un problema con su implementación particular de los métodos predeterminados, no puedo pensar en un problema.