Classes "globais"

Isso é um “singleton”.

(A propósito, a classe SimpleDateFormat não é adequada para ser usada por várias threads simultaneamente. Veja como corrigir esse problema aqui:

Cara quanto ao banco de dados favor ver essa aposila http://www.cin.ufpe.br/~lma2/apostilas/caelum-java-web-fj21.pdf a partir da página 4… Nada a ver essa parada de .ini ae que você fez…

Crie uma classe para Datas que tenha um método static que retorne uma instancia.

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?

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?

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

dúvida #1:

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.

Porque “nada a ver” ?

Porque “nada a ver” ?

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…

Porque “nada a ver” ?

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…

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

Porque “nada a ver” ?

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…

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

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 …

(duplicou )
…

Porque “nada a ver” ?

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…

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.

para um leigo não vai fazer diferença que ele nem vai saber para que usar isso

http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Encrypting_Data_Source_Passwords.html

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!

Obrigado pela ajuda!

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…

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…

Na verdade, usa-se o padrão Factory em combinação com o padrão Singleton:

class ConnectionFactory{
    private  ConnectionFactory instance;

    private String url, user, senha;

    public static synchronized ConnectionFactory getInstance() throws Exception{
        if(instance == null){
              instance = new ConnectionFactory();
              instance.url = leCampoArquivoIni("url");  //esse método você cria
              instance.user = leCampoArquivoIni("user");  //esse método você cria
              instance.senha = leCampoArquivoIni("senha");  //esse método você cria
        }
       
        return instance;
    }

    public Connection getConnection(){
         return DriverManager.getConnection(url,user,senha);
    }
}

Perfeito! Entendi! Ele irá ler o .INI somente uma vez!

Obrigado pelo exemplo!