Devo usar um getter em uma constante ou simplesmente torna-la publica?
Exemplo:
private final static String CARD_NAME = "reservasCard";
public String getCardName(){
return CARD_NAME;
}Se é constante nao precisa estar em um método.
1 curtida
Porque não? No meu ver faria sentido fazer isso…
Não entendi. Você quer dizer que faz sentido ter um getter para um atributo da classe que não pode ser alterado (afinal, é constante) ?
Um getter, nesse caso, sem qualquer processamento adicional, só adiciona uma chamada de método a mais, sem prover qualquer vantagem adicional. Melhor torná-lo público.
Abraço.
Sim, adiciona uma camada e não teria processamento. Mas no meu ver, se essa constante esta dentro de um objeto, então você pediria ao objeto essa variável e não acessaria ele diretamente.
Outro ponto seria que toda a parte do sistema que acessa essa variável, teria que passar por esse get, fazendo um “funil”, se você deseja acessar esse dado você “precisa passar por aqui” obrigatoriamente, facilitaria saber quem acessa isso durante a execução do programa.
Outro ponto seria o retorno, vamos supor que ele tenha que fazer essa alteração futuramente:
private final static String CARD_NAME_DEFAULT = "reservasCardDefault";
private final static String CARD_NAME_RARO = "reservasCardRaro";
public String getCardName(){
if(blablablabla){
return CARD_NAME_DEFAULT;
}else{
return CARD_NAME_DEFAULT_RARO;
}
}
Claro que isso não é regra, são exemplos do porque isso daria sentido pra mim, mas depende do caso.
Se será public, protected, private, depende da visibilidade dela e do uso.
Geralmente, coloca as constantes como publicas, mas isso não deve ser uma regra absoluta.
Depende do caso, as vezes você não quer que sua APÌ fica exibindo os nomes das constantes e canaliza a obrigatoriedade de usar um get por exemplo, ainda que não possa ser alterada.
Mas é uma constante, ou seja, não muda de uma chamada par outra. Acessá-la diretamente como pública ou deixá-la privada e acessá-la através de um método público não faz diferença nenhuma. E a chamada de método só adiciona processamento desnecessariamente.
Mesmo caso acima: é uma constante. Esse funil não adiciona nenhuma funcionalidade ou restrição de acesso, então é redundante.
Isso é diferente do que falei. Note que eu disse que o método não tem nenhum processamento adicional. O seu exemplo possui processamento adicional, o que não é a mesma coisa.
Além disso, se o retorno de um método varia em função de uma condição, melhor que o retorno do método seja de um atributo de uma instância da classe (e o valor desse atributo pode ou não vir de uma constante), ou que haja um método estático que retorne a constante adequada, de acordo com um parâmetro do método.
É possível, mas não vejo o que se pode ganhar com isso, afinal o valor da constante (que é o que realmente importa) ainda pode ser acessado publicamente.
Se a ideia é manter as constantes isoladas dentro do pacote da API, evitando usos por chamadas externas aos pacotes, melhor seria torná-las protected, não?
Abraço.
1 curtida
Não é questão de ganhar e sim de como o programador ou projetista quer as coisas.
As vezes eu tenho uma interface e diversas implementações.
Eu posso precisar, para fins de logging ou exception handling, descrever o tipo do meu objeto. então eu posso ter um metodo Type() e em alguns casos o tipo é uma constante, em outros pode ser algo gerado na hora de criar o objeto.
Imagine que vc tem uma interface Filter e vc quer saber o que é isso. E vc pode ter um filtro ARQUIVO e um filtro TAMANHO menor que 512 bytes e um Filtro que na verdade applica estes dois, então o Type poderia ser CHAINED<FILE, SIZE(max=512)> ( e durante os testes pode ser MOCK , etc )
Faz sentido que algumas strings sejam Constantes. Não faz necessariamente sentido expor como uma coisa publica e, mais importante, na minha semantica faz sentido receber uma string que me de alguma ideia do que é isso, mas a assinatura é o metodo.
Portanto, é tudo um grande “Depende”. Existem vantagens em vc expor CONSTANTES que vc vai usar depois (coleção de status http por exemplo ), mas se diz respeito a classe ou a instância, eu sempre tento pensar se a semantica correta é via Metodo ( pois existem vantagens em acessar um metodo, como quando vc acessa via Reflection, etc ). E se não esta certo, com certas IDEs se torna trivial refatorar isso.
1 curtida
Nossa senhora…, é só uma “constante”, comunidade Java dá muitas voltas pra resolver problemas simples. Só não colocaria o nome em maiúsculo, pois não é const.
1 curtida
Java não tem a palavra reservada const.
Java é bem limitado mesmo. Mas independente disso, nao seria em maiúsculo.
Corrigindo: na verdade a palavra é reservada, mas não é usada, uma vez que declarar uma variável como final tem exatamente a mesma semântica. Até então, não entendi a limitação aí …
Da praticidade da linguagem mesmo, é mais simples const.
Simplesmente porque os métodos existem para modificar ou exibir o estado de um objeto (leia-se atributos) e no máximo de atributos de classe (leia-se variáveis estáticas) e não constantes (já que não são objetos e possuem estado… fixo/constante), olhando do ponto de vista de processamento e consumo de memória, é um overhead desnecessário usar um método para exibir algo que nunca (dinamicamente) vai mudar.
@M4UR0_Dev eu recomendo você estudar um pouco sobre enums em Java
https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
2 curtidas
A questão de maiusculo é apenas convenção, e o static final numa classe (escopo de classe ok?) acaba nunca mudando seu estado pois é carregado junto a classe e não ao objeto (via construtores…), por isso no java acaba tendo o mesmo comportamento de uma const em js, php, etc…
1 curtida
Concordo, mas a linguagem perde em expressividade.
A convencao neste caso é usar maiúsculo no Java? Se for blz, mas fica bem feio, pelo menos no C# não é em maiúsculo, até mesmo usando const.
Exatamente, caixa alta representa constante não só em java, php e js também (mas php tem tanto const quanto define) e python (eu não tenho certeza se possui const nem static final etc, vejo em muitos foruns apenas uma variável simples “convencionada”) e se parar para ver até C ansi com define de macros, mas enfim, eu para ser sincero não me incomodo, no caso do php (minha linguagem principal) até estou bem acostumado…
O código fica gritante, mas se é a convenção da linguagem tem que seguir mesmo.
1 curtida
Tem sim, assim como o goto. Embora essas instruções sejam reconhecidas pela JVM, os compiladores que seguem a especificação, não permitem utilizá-los.
Antes do Java 5 havia ofuscafores gratuitos que introduziam const e goto no bytecode de forma a dificultar a engenharia reversa.
Hoje não sei se existe algum ofuscafor gratuito que o faça.
2 curtidas