Java: ¿clase estática?

Tengo una clase llena de funciones de utilidad. Crear instancias de una instancia no tiene sentido semántico, pero todavía quiero llamar a sus métodos. ¿Cuál es la mejor manera de lidiar con esto? Clase estática? ¿Resumen?

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

Según el gran libro "Java efectivo" :

Artículo 4: imponer la no instantabilidad con un constructor privado

- Intentar imponer 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 instantable al incluir un constructor privado:

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

Debido a que el constructor explícito es privado, es inaccesible fuera de la clase. AssertionError no es estrictamente necesario, pero proporciona un seguro en caso de que el constructor se invoque accidentalmente desde dentro de la clase. Garantiza que la clase nunca se instanciará bajo ninguna circunstancia. Este modismo es ligeramente contradictorio, 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 idioma también evita que la clase se subclasifique. Todos los constructores deben invocar un constructor de superclase, explícita o implícitamente, y una subclase no tendría un constructor de superclase accesible para invocar.

Parece que tiene una clase de utilidad similar a java.lang.Math .
El enfoque allí es la clase final con constructor privado y métodos estáticos.

Pero tenga cuidado con lo que esto hace para la comprobabilidad, le recomiendo leer este artículo
Los métodos estáticos son la muerte de la testabilidad

Solo para nadar río 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 acceder. De esta manera, si necesita anular el comportamiento en cualquier caso en el futuro, no es una reestructuración importante. OO es tu amigo :-)

Mi $ .02

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

no gastes demasiado tiempo para asegurarte de que tu clase no pueda ser mal utilizada. Ten un poco de fe para tus colegas. y siempre hay una manera de usar mal tu clase sin importar cómo la protejas. Lo único que no puede ser mal utilizado es algo completamente inútil.

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

No tiene sentido declarar la clase como static. Simplemente declare sus métodos staticy llámelos desde el nombre de la clase como normal, como la clase de Matemáticas 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 métodos estáticos desde esas instancias. (Estas llamadas funcionan exactamente igual en Java, solo son engañosas y perjudican la legibilidad de su código).

Puede usar la anotación @UtilityClass de lombok https://projectlombok.org/features/experimental/UtilityClass