Eu tenho uma classe cheia de funções utilitárias. Instanciar uma instância dela não faz sentido semântico, mas ainda quero chamar seus métodos. Qual é a melhor maneira de lidar com isso? Classe estática? Resumo?
Eu tenho uma classe cheia de funções utilitárias. Instanciar uma instância dela não faz sentido semântico, mas ainda quero chamar seus métodos. Qual é a melhor maneira de lidar com isso? Classe estática? Resumo?
Respostas:
Construtor privado e métodos estáticos em uma classe marcada como final.
De acordo com o grande livro "Java eficaz" :
Item 4: Aplicar a não instabilidade com um construtor privado
- Tentar impor a não instabilidade tornando uma classe abstrata não funciona.
- Um construtor padrão é gerado apenas se uma classe não contiver construtores explícitos; portanto, uma classe pode ser tornada não instável incluindo um construtor privado:
// Noninstantiable utility class
public class UtilityClass
{
// Suppress default constructor for noninstantiability
private UtilityClass() {
throw new AssertionError();
}
}
Como o construtor explícito é privado, é inacessível fora da classe. O AssertionError não é estritamente necessário, mas fornece seguro caso o construtor seja acidentalmente invocado de dentro da classe. Garante que a classe nunca será instanciada sob nenhuma circunstância. Esse idioma é levemente contra-intuitivo, pois o construtor é fornecido expressamente para que não possa ser chamado. Portanto, é aconselhável incluir um comentário, como mostrado acima.
Como efeito colateral, esse idioma também impede que a classe seja subclassificada. Todos os construtores devem chamar um construtor de superclasse, explícita ou implicitamente, e uma subclasse não teria nenhum construtor de superclasse acessível para invocar.
AssertionError
sobre outras alternativas como IllegalStateException
, UnsupportedOperationException
, etc?
Parece que você tem uma classe de utilitário semelhante ao java.lang.Math .
A abordagem lá é classe final com construtor privado e métodos estáticos.
Mas cuidado com o que isso faz com a testabilidade, recomendo a leitura deste artigo Os métodos estáticos são a morte da testabilidade
Só para nadar contra a corrente, os membros e as classes estáticas não participam do OO e, portanto, são maus. Não, não é mau, mas é sério, eu recomendaria uma classe regular com um padrão único para acesso. Dessa forma, se você precisar substituir o comportamento em qualquer caso no futuro, não será uma grande reformulação. OO é seu amigo :-)
Meu $ .02
comente os argumentos do "construtor privado": vamos lá, os desenvolvedores não são tão estúpidos; mas eles são preguiçosos. criar um objeto e chamar métodos estáticos? não vai acontecer.
não gaste muito tempo para garantir que sua classe não possa ser mal utilizada. tenha um pouco de fé para seus colegas. e sempre há uma maneira de abusar da classe, não importa como você a proteja. a única coisa que não pode ser mal empregada é completamente inútil.
Não faz sentido declarar a classe como static
. Apenas declare seus métodos static
e chame-os do nome da classe como normal, como a classe Math de Java .
Além disso, mesmo que não seja estritamente necessário tornar o construtor privado, é uma boa ideia fazê-lo. Marcar o construtor como privado impede que outras pessoas criem instâncias da sua classe e, em seguida, chame métodos estáticos a partir dessas instâncias. (Essas chamadas funcionam exatamente da mesma forma em Java, são apenas enganosas e prejudicam a legibilidade do seu código.)
Você pode usar a anotação @UtilityClass do lombok https://projectlombok.org/features/experimental/UtilityClass