[quote=pcalcado]
mAs… o que tem a ver o snchronized? Estático ou não, você teria o mesmo problema.[/quote]
também acho, não é porque os métodos ou atributos são estáticos que você vai ter problemas de concorrência.
O problema de concorrência independe da estaticidade deles.
Sobre usar ou não, prefiro usar somente para constantes, para métodos de classes utilitárias, e para realmente compartilhar dados em um objeto que seja singleton, de resto ignore a utilização sempre.
Sobre DAO, ainda vejo um armengue para adapatar linguagens O.O. com bancos relacionais.
Bom galera obrigado pela ajuda, consegui argumentos suficientes para defender minha preferencia pelo modelo não estático, e já convenci o programador a fazer assim tb, obrigado.
[quote=Fabrício Cozer Martins][quote=pcalcado]
mAs… o que tem a ver o snchronized? Estático ou não, você teria o mesmo problema.[/quote]
também acho, não é porque os métodos ou atributos são estáticos que você vai ter problemas de concorrência.
O problema de concorrência independe da estaticidade deles.[/quote]
Masomeno. Se uma instância nunca escapar da thread então você não precisaria se preocupar com acessos concorrentes em métodos de instância mas com os métodos estáticos não tem como ter essa garantia. No caso de DAOs isso não importaria porquê é fácil escrever os métodos para funcionar concorrentemente (sem synchronized…). Mas dizer que em geral “O problema de concorrência independe da estaticidade” não é verdade.
Se quando terminar a lógica de negócio o seu dao estiver disponível para coleta de lixo, e se o seu DAO for peso leve para ser instanciado, não vejo problemas.
Pergunto isso pois acho disperdício de memória e também pq estou desenvolvendo uma aplicação RMI e tenho que preocupar com tudo isso, inclusive para as classes de negócio.
eu chamo de peso leve objetos que não são pesados de ser instanciados.
Se seu DAO for simples e não fica carregando um monte de recursos durante a instanciação, não vejo problemas em instanciá-lo cada vez que precisar dele.
