Me refiero, por ejemplo, a tener una clase utilidad,
public class BasicValidations {, que se llama así, pese a todos los warnings del mundo que nos pone el Eclipse
public static boolean isNIF(String str) { .... }
public static boolean isCIF(String str) { .... }
public static boolean isNIE(String str) { .... }
}
new BasicValidations().isNif("11111111H");Pues podemos hacer algo. Evitar que nos lo sigan haciendo. Incluso hacer entender el porqué. Pongamos un constructor privado en la clase.
public class BasicValidations {A lo mejor así seremos un poco más felices al ver cómo usan nuestro código.
private BasicValidations() {}
public static boolean isNIF(String str) { .... }
public static boolean isCIF(String str) { .... }
public static boolean isNIE(String str) { .... }
}
Xa é triste, ter que crear constructores en clases pensadas para usar como estáticas sólo para que algún gañán non faga o que non debe.
ResponderEliminarEu, nestes casos, son partidario do método do leñazo na nuca, é moito máis satisfactorio.
De hecho, el constructor privado es un gran aliado si la clase está pensada para acceder sólo a métodos de utilidad. Me parece una buena práctica muy recomendable. Si la clase en algún momento pasa de "stateless" a "stateful", entonces será el momento de dejar accesible el constructor o desenterrar a nuestro viejo amigo el "singleton".
ResponderEliminarY que conste que a veces lo del leñazo en la nuca es una tentación difícil de resistir ;)