Classe static - Compartilhamento entre instâncias

10 respostas
sublyer

Tenho uma classe chamada Erro que é static, que contem a listagem de erros que foram encontrados em um determinado processo de execução do meu sistema.

Esta classe Erro é chamada em mais de um processo de execução (duas instâncias ao mesmo tempo), então pergunto a vocês, ela é compartilhada entre as outras instâncias? ja que para acessar ela não é necessário instânciar a classe?

Obrigado por quem puder me ajudar.

10 Respostas

doug

O que aconetce que vc vai colocar as instancias objetos no list ou array…
mas sua Classe erro deve ter um metodo get e set para esse Array…
só assim vc consiguirá guardar todas as instancias dos objetos dento do list

blz…
flwssss
espero ter ajudo

nbluis

Se entendi bem.

Aqui tem uma discussão sobre esse assunto.

Talvez ajude.

peczenyj

Não seria mais interessante vc usar um logger como o log4j ?

Vc estaria criando, usando um método estatico, uma ‘ligação’ muito forte entre as suas instâncias. Alias vc pode ter problemas de acesso concorrente. Pense bem :wink:

sublyer

Entendi, meu caso se resume assim:

Tenho minhas camadas de visualização:

1ª - Web
2ª - Mobile

Tenho minhas classes com método que fazem acesso ao BD, mas antes de enviar os dados para o BD, tenho que fazer algumas consistências,
utilizando um list de string por exemplo, posso verificar todos os erros que estiverem acontecidos, enviando esses erros ao cliente (web ou mobile).
Se eu utilizar uma classe static, se dois acessos forem feitos simultaneamente(um pela web e outro por mobile) o acesso web registra 2 erros, e então automaticamente quando eu “puxo” a listagem de erros pelo cliente mobile, que não teve nenhum erro a executar o método com acesso ao bd, me volta os dois erros do cliente web, correto?

Pensei em utilizar os erros na forma de exception, pois assim o cliente trava as excessões de acordo com sua instância.

O que vocês acham?

sergiotaborda

sublyer:
Tenho uma classe chamada Erro que é static, que contem a listagem de erros que foram encontrados em um determinado processo de execução do meu sistema.

“Erros de um determinado processo” já indica que a classe não pode ser estática (global).
É simplesmente um erro de modelagem.

Por outro lado não ha razão para transformar suas exceções numa listagem de erros. Primeiro porque apenas um erro acontece por vez. Segundo as exceções não devem ser aniquiladas. Elas devem ser lançadas e capturadas pela camada mais exterior. No seu caso a camada web e a camada mobile. Se chegadas nesta camada nada pode ser feito , ai vc loga, transforma para mensagem, e mostra ao usuário. mas apenas nesse caso.
Se o mobile é feito via algum padrão seu tlv vc queira converter para mensagem antes de enviar ao mobile.
Neste sentido a sua camada mais exterior é a interface mobile-web. Se a conexão é feita via webservice por exemplo, as exceções serão propagadas até ao mobile. Tudo depende como é a sua arquitetura.
Sempre deixe as exceções subirem nas camadas o máximo possivel.

LPJava

so uma duvida… temos classes static em java? até onde sei nao temos super-classe como static…
Se colocar o codigo é mais facil ate de identificar o seu problema… e tirar sua duvida.

flW

sublyer

Quando você diz "Sempre deixe as exceções subirem nas camadas o máximo possivel. ", você quer dizer que tenho que propagar as excessões até aonde foi feita a chamada do método que fez com que a excessão fosse lançada, correto?

Flwww

peczenyj

sublyer:
Quando você diz "Sempre deixe as exceções subirem nas camadas o máximo possivel. ", você quer dizer que tenho que propagar as excessões até aonde foi feita a chamada do método que fez com que a excessão fosse lançada, correto?

Flwww

IMHO, se vc tem exceptions, vc tem que trata-las de forma adequada ao teu modelo.

O que fazer depende da tua aplicação, mas em algum momento um erro significa que vc tem que desfazer algo, fechar algo que esta aberto, liberar um recurso ou tentar de novo mais tarde.

O motivo pelo qual ocorreu o erro deve ser identificado sim, para isso vc tem extratégias de logging, paginas/telas de erro, testes unitários, etc. Pense em cada erro e o seu motivo. Alguns erros vc vai criar um mecanismo adequado para tratar dele, outros podem ser erros inesperados, como RuntimeExceptions vindo de lugares obscuros (aquele array que vc pega um indice sem verificar os limites, por exemplo) e vc pode identificar que tem que trata-los também. Como vê, o assunto é complexo.

Perceba que a frase tem a palavra ‘possivel’, logo não é a ultima cada sempre, pode ter uma intermediaria :slight_smile:

sergiotaborda

sublyer:
Quando você diz "Sempre deixe as exceções subirem nas camadas o máximo possivel. ", você quer dizer que tenho que propagar as excessões até aonde foi feita a chamada do método que fez com que a excessão fosse lançada, correto?

O peczenyj já respondeu o mais importante: a palavra chave é “possivel”.
Se a ordem de chamada é A->B->C->D->E->F e o erro aconteceu em E então A,B,C e D terão a oportunidade de tratar o erro. Se nenhuma o fizer cabe a A, a ultima, fazê-lo obrigatoriamente. Mas se o erro poder ser tratado ( i.e. corrigido) antes, tanto melhor.

O mesmo conceito se aplica se A, B … F são camadas em vez de métodos.
Normalmente A é uma camada de interface. Para estas camadas a exceção é um dado bruto. Ele tem que ser transformado para poder ser apresentado. Normalmente numa mensagem user-friendly. Esta tarefa deve ser da camada de apresentação e nunca das outras.

Lembre-se apenas que logar não é um tratamento aceitável nas camadas intermédias ( isso não resolve o problema) mas é correto na camada final antes de ser traduzido para uma mensagem user-friendly

sublyer

Agora entendi… :smiley: obrigado a todos.

Criado 14 de janeiro de 2008
Ultima resposta 14 de jan. de 2008
Respostas 10
Participantes 6