Já andei lendo bastante coisa aqui no fórum sobre o que chamávamos de variáveis globais em linguagens procedurais, mas as respostas ainda não conseguiram me esclarecer essa dúvida.
Por exemplo, utilizo em todo o meu projeto um SimpleDateFormat dessa maneira:
SimpleDateFormat dataView = new SimpleDateFormat("dd/MM/yyyy");
mas tenho que criar o objeto dataView em qualquer que preciso desse SimpleDateFormat
Não teria alguma maneira de instanciar esse objeto uma única vez e quando precisar, apenas utilizar dessa forma?
dataView.format(dcDataInicial.getDate())
Da mesma forma, a conexão com o banco, que tenho o login e senha em um arquivo .INI. Todas as vezes que preciso fazer uma consulta, estou tendo que ler o .INI para capturar o login e senha… não teria como instanciar a conexão com o banco e utilizá-la durante toda a execução?
Sei lá se consegui explicar direito…acho que é um item super básico, mas por não saber nem ao certo como esse recurso se chama, fica complicado até de fazer novas consultas no fórum… deve ter vários tópicos abertos sobre isso…
hehehe! Pelo comentário do tunai, chega a me arrepiar as coisas que programamos! Muitas vezes os softwares funcionam, mas nem mesmo o programador saber o porquê! Certamente se abrir meu código, vocês ficariam horrorizados!! Mas obrigado pela apostila! Já dei uma “paginada” e me parece muito boa mesmo!
A ideia do Kazdum é boa também! Se eu verificar que a classe já está instanciada, torna-se um singleton, não é isso?
[quote=marcosperes]hehehe! Pelo comentário do tunai, chega a me arrepiar as coisas que programamos! Muitas vezes os softwares funcionam, mas nem mesmo o programador saber o porquê! Certamente se abrir meu código, vocês ficariam horrorizados!! Mas obrigado pela apostila! Já dei uma “paginada” e me parece muito boa mesmo!
A ideia do Kazdum é boa também! Se eu verificar que a classe já está instanciada, torna-se um singleton, não é isso?
[/quote]
No caso dessa classe pra data eu não te recomendaria fazer isso não… Faça uma função então que retorne um objeto SimpleDateFormat com a data já formatada!
Você poderia criar um atributo publico e estático assim quando você for usar ele você só instanciará ele uma vez.
Quando uma variável é estática ela pode ser acessada por qualquer instancia daquela classe em questão, se for publico o acesso e para todas as classes, um exemplo clássico é para contar quantas instancia de uma classe foram criadas
public class obj {
public static int contagem = 0;
public obj(){
contagem++;
}
}
public class init {
public static void main(String... args){
for(int i = 0 ; i < 10; i++){
new obj();
}
SYstem.out.println(obj.contagem);
}
}
você pode ver que quando eu acessei o int contagem eu não precisei usar nenhuma instancia para chegar até ele pois ele é estático, ou seja todas as instancias terão o mesmo objeto o mesmo valor, se uma instancia muda o valor dele ele será alterado em todos
Uma prática comum é criar uma classe DataUtil ou FormatUtil com um método static formataData() que te retorna a data no formato desejado, usando o SimpleDateFormat. Você pode usar também o métod static String.format() .
dúvida #2:
Cara, não tem problema nenhum colocar os parâmetros de conexão com o banco em um arquivo separado. É exatamente isso que fazem os servidores de aplicação e os frameworks de persistência. Mas de fato, é inconveniente ficar lendo o arquivo a todo momento. Para tanto, um padrão de projeto muito utilizado é a famosa Factory, em português, Fábrica.
Uai cara, se você não vê problemas em colocar a senha em um arquivo onde qualquer um irá ter acesso então coloque! Acho que o arquivo .ini serve mais para configurações da aplicação, colocar senha no arquivo eu particularmente não gosto. Ainda mais que é possível configurar na própria classe de maneira que você pode alterar os dados a qualquer momento, se não for por uma necessidade específica não consigo ver o pq fazer isso…
Uai cara, se você não vê problemas em colocar a senha em um arquivo onde qualquer um irá ter acesso então coloque! Ainda mais que é possível configurar na própria classe de maneira que você pode alterar os dados a qualquer momento, se não for por uma necessidade específica não consigo ver o pq fazer isso…[/quote]
entenda que a senha estando num arquivo ou estando no código do programa java, ambas as formas são perigosas e qualquer um pode pegar a senha partir disso, um programa java não é difícil de decopilar assim se auguem quiser ler o seu código fonte não teria problema nenhum
Uai cara, se você não vê problemas em colocar a senha em um arquivo onde qualquer um irá ter acesso então coloque! Ainda mais que é possível configurar na própria classe de maneira que você pode alterar os dados a qualquer momento, se não for por uma necessidade específica não consigo ver o pq fazer isso…[/quote]
entenda que a senha estando num arquivo ou estando no código do programa java, ambas as formas são perigosas e qualquer um pode pegar a senha partir disso, um programa java não é difícil de decopilar assim se auguem quiser ler o seu código fonte não teria problema nenhum[/quote]
Concordo com você! Inclusive já fiz isso com um amigo, mas é mais fácil para um leigo por exemplo abrir um arquivo do que pensar em exrair o jar e ler o .class …
Uai cara, se você não vê problemas em colocar a senha em um arquivo onde qualquer um irá ter acesso então coloque! Acho que o arquivo .ini serve mais para configurações da aplicação, colocar senha no arquivo eu particularmente não gosto. Ainda mais que é possível configurar na própria classe de maneira que você pode alterar os dados a qualquer momento, se não for por uma necessidade específica não consigo ver o pq fazer isso…[/quote]
Na prática, configurações de banco de dados quase sempre são colocadas fora do código fonte. Justamente para que você tenha a liberdade de reconfigurar a aplicação sem precisar recompilar o código. É comum usar até 2 níveis de indireção nesse caso, quando se usa JPA/Hibernate por exemplo. Por exemplo, EntityManagerFactory --> persistence.xml --> context.xml. Com relação a segurança nesse caso, há outras maneiras de provê-la. O mais simples é restringir o acesso ao servidor ou ao diretório em que está a configuração do banco de dados. Eu não lembro bem agora, mas para o JBoss pelo menos, você pode criar um arquivo com a senha criptografada e configurar o servidor para ler a senha a partir desse arquivo.
Mas isso complementa a dica da apostila: para quem vai trabalhar só com JDBC, o ideal é criar uma classe ConnectionFactory que leia as configurações de um arquivo ou outra fonte e que abra as conexões, isolando essa tarefa do resto da aplicação.
Eu gosto de ler os .INI para ficar fácil alterar o endereço do servidor, por exemplo.
Em aplicações de automação comercial, muitas vezes precisamos fazer isso, e poder redirecionar a conexão apenas alterando o .INI facilita bastante!
Agora, criptografar a senha seria sem dúvida uma segurança! Vou estudar isso!
[quote=marcosperes]Então Rodolfo, sobre a dúvida 2, li sobre factory, mas me perdoe, não entendi muito bem como consigo aplicar isso na leitura de um arquivo .INI…
Não teria que ficar acessando o arquivo todas as vezes que chamar uma classe que faz essa leitura?
Me perdoe, não pesquei esse padrão…
[/quote]
Na verdade, usa-se o padrão Factory em combinação com o padrão Singleton:
)