java class oop static utility

Java: ¿clase estática?



jradiobutton (7)

Constructor privado y métodos estáticos en una clase marcada como final.

Tengo una clase llena de funciones de utilidad. Instanciar una instancia de la misma no tiene sentido semántico, pero aún quiero llamar a sus métodos. ¿Cuál es la mejor manera de lidiar con esto? Clase estática? ¿Abstracto?


De acuerdo con el gran libro "Effective Java" :

Elemento 4: imponer la no instantabilidad con un constructor privado

- Intentar forzar la no instantabilidad haciendo un resumen de clase no funciona.

- Se genera un constructor predeterminado solo si una clase no contiene constructores explícitos, por lo que una clase puede hacerse no instalable incluyendo un constructor privado:

// Noninstantiable utility class public class UtilityClass { // Suppress default constructor for noninstantiability private UtilityClass() { throw new AssertionError(); } }

Como el constructor explícito es privado, es inaccesible fuera de la clase. El AssertionError no es estrictamente obligatorio, pero proporciona un seguro en caso de que el constructor sea invocado accidentalmente desde dentro de la clase. Garantiza que la clase nunca se instanciará bajo ninguna circunstancia. Este modismo es levemente contrario a la intuición, ya que el constructor se proporciona expresamente para que no se pueda invocar. Por lo tanto, es aconsejable incluir un comentario, como se muestra arriba.

Como efecto secundario, este modismo también impide que la clase sea subclasificada. Todos los constructores deben invocar un constructor de superclase, explícita o implícitamente, y una subclase no tendría un constructor accesible de superclase para invocar.


No tiene sentido declarar la clase como static . Simplemente declare que sus métodos son static y llámelos desde el nombre de la clase como normal, como la clase de java.lang.Math de Java.

Además, aunque no es estrictamente necesario hacer que el constructor sea privado, es una buena idea hacerlo. Marcar el constructor como privado evita que otras personas creen instancias de su clase y luego llamar a los métodos estáticos de esas instancias. (Estas llamadas funcionan exactamente igual en Java, simplemente son engañosas y perjudican la legibilidad de su código).



Solo para nadar aguas arriba, los miembros estáticos y las clases no participan en OO y, por lo tanto, son malvados. No, no es malo, pero en serio, recomendaría una clase regular con un patrón singleton para el acceso. De esta manera, si necesita anular el comportamiento en cualquier caso, no es una reorganización importante. OO es tu amigo :-)

Mi $ .02


comente sobre los argumentos del "constructor privado": vamos, los desarrolladores no son tan estúpidos; pero ellos son perezosos. crear un objeto y luego llamar a los métodos estáticos? No va a pasar.

no dedique demasiado tiempo para asegurarse de que su clase no pueda ser mal utilizada. tener algo de fe para tus colegas. y siempre hay una manera de utilizar mal tu clase sin importar cómo la protejas. lo único que no se puede usar indebidamente es algo que es completamente inútil.


  • Clase final y constructor privado (bueno pero no esencial)
  • Métodos estáticos públicos