[quote=entanglement]Se alguém de vocês é um programador Linux/Unix, eu comparo a situação de botar statics no programa inteiro com a de criar um programa que só roda como o usuário “root”, só porque não entendeu como se lida com as permissões de uso dos arquivos e outros recursos.
Isso costuma indicar que o programador não entendeu alguma coisa e ficou com preguiça de correr atrás para entender como é que se fazem as coisas corretamente. [/quote]
Concordo.
Existe um argumento, muito usado nas discussões com programadores C++, de que “ah, mas se o erro é assim, é porque a culpa do programador”. Eles geralmente usam isso quando demonstramos alguma coisa que a linguagem é capciosa e induz ao erro. Como por exemplo, nas discussões sobre ainda usar ponteiros versus usar linguagens gerenciadas.
É um argumento que detesto porque, no firgir dos ovos, todo e qualquer erro de software é um erro de programador. Com um argumento desses, você pode até dizer que assembly é fácil, e que se houver algum problema, é erro do programador.
A diferença é que bons programadores criam designs de software que promovem a ausência de erros:
Criam abstrações que os impeçam de mexer nas variáveis em contextos que não deveriam;
Criam testes unitários e verificam parâmetros de entrada;
Fazem o compilador trabalhar por eles em verificações;
Programar em modo root ou programar só usando statics é possível, mas é o que um programador ruim faria. Afinal, é pedir para ter problemas, sem um argumento técnico suficientemente convicente para isso.
[quote=ViniGodoy]Sim, Gilson, como já falamos no tópico os problemas são quando aparecem variáveis estáticas. Como eu já havia explicado, após o post do Bruno, se o método estático tiver só variáveis locais, nem mesmo sincronização será necessária.
Eu mesmo, na minha primeira afirmação, não falei que métodos estáticos fossem o problema per se, mas sim, que são mais difíceis de se gerenciar em multi-threading. E isso são, pois você terá que cuidar justamente para variáveis estáticas não aparecerem e terá que gerenciar com mais cuidado os locks que eles utilizarem. Ou, acaba enfileirando seu sistema inteiro.
Porém, o tema central do tópico é “utilizar métodos muitos estáticos por todo o programa”. Nesse caso, usar isso como política de desenvolvimento, com a intenção de obter performance, irá promover o aparecimento de variáveis desse tipo. E, consequentemente, estragar um possível paralelismo do sistema, com um resultado muito mais drástico à performance do que o custo de invocação tem. [/quote]
Isso só vale se quando o método estático usa uma variável compartilhada (leia-se, externa ao método), não é Vini?[/quote]
Acredito que sim, devido ao escopo… ou estou errado ???
Como sempre evitei métodos estáticos, fiquei na duvida se este código pode apresentar problema:
public static String converterDataString(Date cal, String formato) throws CoreException {
try {
SimpleDateFormat sdf = new SimpleDateFormat(formato);
String dataStr = sdf.format(cal);
return dataStr;
} catch (Exception ex) {
throw new CoreException("Erro em converterDataString.", ex);
}
}
[/quote]
Gostaria de saber um pouco mais sobre isso, alguem recomenda algum artigo? Vale a pena eu alterar um sistema antigo com um método static similar ao citado aqui?
OBS.: O método static em questão é usado em diversas servlet, que por sua vez possuem diversas threads.
A questão final é o trabalho compensa? Todos os outros comentários me levaram a entender que não. O problema é essa frase: [quote=ViniGodoy]a) Métodos estáticos são mais difíceis de usar em contextos de multiplas threads - o que pode ter um impacto significativamente ruim na performance;[/quote]
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Dizer antigo mas funcional mesmo… Veja bem ach que o que Vini quiz dizer foi que quando você usa muitos métodos státicos tem-se um grande problema em realação ao acesso. E Threads trabalha em cima disso, claro. Então se um método estático só pode ser visto por outro estático, imagine se você quer atualizar através de um não-estático, imagina isso em diversas Threads, como encontrar o erro???
Porisso torna o código menos legível com toda certeza!