Bom estou com uma dúvida em relação ao criar uma Class para a utilização de forma estática meus caminhos dentro de um projeto. Onde eu me deparei com um problema criar ou não ?
Tendo em vista que tem suas vantagens de desvantagens. Vou citar algumas que eu notei:
Vantagens
Com menos ou sem duplicação de caminho
Reaproveitação de caminho (string)
Facilitação da alteração do caminho
Concentração das constantes em uma classe (util)
Desvantagens
Documentação da classe para o uso dessa Classe dentro do projeto(sendo que pode ocorrer dela não ser utlizada)
Duplicação devido a relação de cima.
Pode não haver reaproveitamento do caminho
Não é tão legivel (bom pelo menos para mim )
Bom citei alguns benefícios e problemas que eu vejo na utilização dessa abordagem, claro que há mais, mas estou apenas citando algumas.
Bom na minha opinião eu prefiro usar uma classe com constante.Apesar dos pesares.
Mas vocês utilizam isso no seus projetos ? E como lidam com o problemas que encontram quando alguém novo entrar para desenvolver um projeto e não saber que ao menos ela exista?
Então se alguém movimenta um arquivo para um diretório diferente acontece de ele não conseguir encontrar o arquivo a página que seria o padrão %NotFoundException ou erro 404.
Bom por isso que eu prefiro utilizar a constante pois pode ser que exista muitas parte em que o caminho esteje sendo utilizado e caso você precise trocar pode ser feita em apenas uma classe sendo ela reaproveitada, apesar de considerar o não uso da mesma por questão de documentação dentro de um projeto.
paths e valores que podem mudar eu sempre deixo em arquivos properties, geralmente eu parametrizo o que posso na aplicação para não deixar nada fixo em códigos, mas eu não conheço seu software e o real propósito dele, mas se os paths fossem para acessar recursos internos da aplicação e isto fosse muito utilizado pelo código, a resposta é sim eu deixaria em uma constante.
Hum entendo, você usaria mais pelo fato de ter caminhos em que você vai usar internamente de forma que posso agrupar em algum lugar.
Mas @aix você aplica isso em todos seus projetos e os projetos que você já acompanhou havia isso implantado neles ? E em relação a sua devida documentação para utilização da mesma, como sua equipe lidava com isso sabendo que centanas de pessoas podem estar alterando o projeto ?
Isso mesmo, ficar centralizado em um local é bom. Geralmente as únicas classes ou Interface Java(constantes) que tenho, são mensagens customizadas de exceção de negócios do sistema ex:
public interface ExceptionConstants {
public static final String NAO_E_POSIIVEL_EXCLUIR_O_REGISTRO_HA_DEPENDENCIAS = "Não é possível excluir o registro, pois há dependências.";
public static final String IP_DO_CLIENTE_OBRIGATORIO = "IP do cliente é obrigatório";
public static final String EXISTE_REGISTRO_SEMELHANTE = "Já existe um registro semelhante.";
public static final String NAO_E_POSSIVEL_DESABILITAR_USUARIO = "Não é possível desabilitar o usuário.";
public static final String SENHA_ATUAL_NAO_CONFERE = "Senha atual não confere.";
public static final String CONFIRMACAO_NOVA_SENHA_NAO_CONFERE = "Confirmação da nova senha não confere.";
public static final String SENHA_NAO_PODE_SER_IGUAL_A_SENHA_ATUAL = "Nova senha não pode ser igual a senha atual.";
...
Mas nunca tenho para Paths, mas como falamos acima, se fosse para Paths de recursos internos da aplicação e eu utilizasse muito ai sim prefiro utilizar constantes do que ficar escrevendo String pelo código de maneira repetitiva.
Para Paths sempre utilizo arquivos properties.
Pó achei bem legal a sacada de usar a interface como constante sempre usei de forma abstrata. Assim eu posso implementar a classe e usar as constantes diretamente e também posso usar passando de forma estática e simplesmente mesmo trocando de classe para interface isso não quebraria o projeto .
public class Exemplo implements ExceptionContants{
private String execaoSenha = SENHA_ATUAL_NAO_CONFERE;
// ou posso usar de maneira estatica
private String exceptionSenha = ExceptionConstants.SENHA_ATUAL_NAO_CONFERE;
}
Bom mas referente a sua resposta eu sempre usei de forma contraria que há sua, os properties como é um padrão da maioria dos Frameworks(Web Java) do mercado usar um messages.properties para validação, erros, e para internacionalização, já caminho sempre utilizo ele dentro do código ou vinda do banco.
Exemplo em Ruby:
Pathname.new("/usr/lib")
# Assim seria usando uma constante
Pathname.new(Meupath.USER_LIB)
Mas o grande problema quando muitas pessoas estão dando manutenção ou criando sempre varia-se a maneira com que é utilizado pode ser da primeira maneira do exemplo ou da segunda, como eu expliquei pode ocorrer de ter duplicatas do mesmo caminho eu gostaria de saber como eu posso obrigar eles a utilizarem a classe “MeuPath” como principal ?
Agora entendi onde você quis chegar :), bom eu também faço assim como você falou mas na verdade depende muito do projeto, tenho de ambas as formas, mas voltando ao foco da sua dúvida realmente é muito dificil garantir isso no projeto, porque o desenvovledor tem acesso a classe e sempre que tivermos acesso a classe podemos mudar seu comportamento, então a melhor forma é uma documentação clara da arquitetura do software.
No momento em que estou escrevendo para você fiquei pensando e se você especializasse seu bean de tela? na spec diz que quando você especializa seu bean o primeiro é desabilitado, veja: If a bean is specialized by any enabled bean, the first bean is disabled. mas é só uma idéia que veio a mim, teriamos que testar.
Entendi o jeito que você pensou seria meio que uma Overide da herança (mas isso em uma anotação) ; Mas não entendi como aplica-ló.
Bom eu vejo como o grande problema eles não terem recebido uma interface em vez de denominar uma String como parâmetro para um caminho, em suas devidas libs (methods).
Bom, você pode fazer algo como um interceptor da request alterando o comportamento default, ex:
@Intercepts
@Specializes
@RequestScoped
public class CustomViewInterceptor extends View {}
No meu ponto de vista faz todo sentido ser assim, os caminhos são relativos ao dominio, se a classe recebesse uma interface continuaria dependendo de uma implementação, é por isso que gosto do Vraptor como controller web, ele é muito flexível, você pode alterar o comportamento do que quiser e mapear como quiser suas URL’s .
Hum legal @aix, muito obrigada pela sua opinião e sua resposta.
Ainda não desenvolvi nem li nada sobre o VRaptor apesar de ter visto algumas palestra com o pessoal da Caelum, mas vou tentar dar uma olhada melhor sobre o framework.
)
)
.