| Autor |
Mensagem |
|
|
Leonardo3001 wrote:
Um passo é mais rápido que dois passos, obviamente. Mas sua aplicação não rodará duas vezes mais rápido só porque você teve preguiça de usar OO e usou static em tudo quanto é quanto. O motivo é simples: a instanciação de objetos não é parte mais custosa de aplicação. O que é custoso é mandar queries no banco de dados, escrever arquivos, enviar dados via rede, fazer serialização, parsear XML... Ou seja, instanciar ou não objetos é coisa ínfima, perto de muitas outras coisas.
Leonardo3001,
Nao estamos pensando em fatores de midleware, somente num simples trecho de codigo java ao maximo da performance...
Pelo que vejo, vc ja esta concordando comigo em alguma coisa:
1 processo e mais rapido que 2....
Portanto se com um metodo static eu evito um processo de instanciaçao, vemos que um static por mais desaconselhavel de praticas de design, J2EE e etc, e mais rapido e nao podemos negar!
Quando vamos começar a pensar que o simples gera o avançado, e nao pensar que nem sempre temos memoria em todos os dispositivos.. ja pensou se um aplicativo java da Nasa pudesse usar o que um simples cadastro exige num mero PC!!
|
 |
|
|
victorwss,
Muito boa boa sua explicaçao, gostei mesmo.
Mas nesse momento nao teriamos que concordar com o ccaneta?
Quando diz que o fato de usar uma classe carregada usaria menos memoria e evitaria o tempo de instanciar uma classe, ao contrario do new em que temos que carregar e depois instanciar?
Pensando assim usar um static seria mais vantajoso?
Eu penso logicamente que 1 passo e sempre mais rapido que 2 passos, agora nao sei a opiniao de voces em relaçao a isso..
O que vcs opinam?
|
|
|
|
Marcio Duran wrote:
O Mundo é Hacker "Ninguém é inocente mas todos se calam"
Gostei dessa frase, ela resume como o GUJ atua no mercado de TI.
rs!!!
|
|
|
|
Marcio Duran,
Acredito que o caos gera dinheiro, trabalhar em um projeto zoado, tudo baleado, codigo so dando erro é o melhor. 
Ainda mais quando ganhamos por hora extra, e nao adianta negarem, pois o que o ser humano quer é dinheiro na conta!
Vemos os EUA soltando uma bomba no Iraque, dizendo terrorismo é ruim, quando na verdade querem e o petroleo.
Qtas vezes vemos um gerente de uma empresa ganhar um dinheiro por fora, pq contratou aquela consultoria X, e estava botando mais gente alocada na empresa e mamando sobre cada hum X% percentual.
E a vida, nao adianta negar que nunca viu isso! Pois ai seria uma outra mentira...
O mercado de TI pode ser bonito, com ohh aquela tecnologia, ohh aquele framework... mas o que sera que aqueles CEOS ou diretores estao pensando? dinheiro x dinheiro! Sera que vai sobrar algum pra mim fora meu salario?
Muitas vezes pensamos nossa este codigo lindo, rapido, usa o melhor framework... meu chefe vai adorar!
Ai so no pensamento do chefe, tomara que de mais pau, pois ai vou ganhar mais dinheiro sobre esse programador via consultoria... !
O mundo capitalista é uma imensa jogatina, que muitos tentam dizer q nao existe!
|
|
|
|
O bom e trabalhar onde tem caos, afinal caos gera dinheiro pro consultor....
Qtos gerentes nao ganham metendo consultorias num projeto, e contratando profissionais q nem sabem programar... mas o gerente da consultoria X lhe da uma graninha por fora!
Pois e! vivemos num mundo capitalista!!
|
|
|
|
Marcio Duran,
Seu post é realmente bem interessante, existem varios fatores a se reflexionar sobre como os frameworks evoluem perante as demandas de mercado....
Muitas vezes penso, "nada se cria, tudo se copia!"
E isto se vc for ver, e a mais pura verdade, qtos frameworks derivaram de outros, uma linguagem hibrida como c++ saiu e todos usaram... acredito que as vezes nem pq é bom todos querem, e sim pq a moda dita ou quiz!
Tecnologia e necessidade, mas muitas vezes uma moda dita um rumo. Alguem diz Java e melhor, VB e um lixo, ou XX e o pior... Nao acredito q as vezes programar e importante, mas entender um requisito e poder determinar um simples escopo e mais importante que bits.
Pois no final todos somos usuarios, de computador, de um sistema de saude, como pagador de contas num banco... Cadastro sobre cadastros, o poder da informaçao dita o rumo de um país!
QUEM TEM INFORMAÇAO, TEM O PODER DE MANDAR!!
EHEHE
|
|
|
|
Ninguem poderia ajudar com a minha dúvida, por favor? 
|
|
|
|
Ola pessoal,
Uma duvida:
O processo que o modificador static faz nao e a mesma ideia que uma Reflection ?
Sempre que dizemos que um Reflection e mais lento do que dar um new, certo??
Portanto teria que dizer que o static e mais lento tb que fazer uma instanciaçao, nao e?
Qual o opiniao de vcs nisso?
abrs
|
|
|
|
Mauricio Linhares,
Por favor, so responda a minha pegunta! Pois e uma questao de logica de associaçao...
Afinal e educaçao respeitar a opiniao do outros.
abrs
|
|
|
|
Thingol,
Entao podemos dizer que qdo eu faço uma Reflection de uma classe, estou carregando da mesma forma que um static faz?
Se eu pensar neste modelo, sempre que dizer que um Reflection e mais lento do que dar um new, certo?? Teria que dizer que o static e mais lento tb, nao e?
O que vc acha disso?
|
|
|
|
Thingol,
O que vc quiz dizer e que qdo eu uso o new passo pelo construtor, e qdo chamo o metodo static direto nao posso pelo construtor... certo???
Agora me explique, pra eu carregar uma classe eu nao preciso instanciala internamente? Nao entendo como posso carregar algo sem automaticamente instanciar, vejo como um processo sequencia... ? Mesmo que o construtor nao seja invocado, instanciar e uma forma de carregar....
Posso pensar que o T.show() e uma outra forma de instanciar uma classe na memoria sem passar por um construtor... tipo, a VM faz uma instancia diferenciada pro static...
Nao acha algo logico isso?
|
|
|
|
thingol wrote:
A chamada a um método estático de uma classe não envolve instanciar essa classe, apenas carregá-la. Portanto o que você disse está errado. Uma forma de você saber isso é criar um construtor e ver quantas vezes esse construtor é chamado: ele será chamado apenas 1 vez.
Thingol,
Isto de ser chamado 1 vez nao acontece.. fiz ate o exemplo e veja:
OutPut:
ddd
ddd
T
ddd
T
ddd
Cade essa unica vez q vc falou???
|
|
|
|
Por favor, me expliquem a diferença na memoria neste codigo static.
NAO adianta dizer q de uma forma eu crio uma instancia e na outra nao com o uso do new, pois penso q no final tudo se cria uma instancia internamente na VM. Pelo que li nos post acima, o desempenho seria igual nos 2, mas o q difere um do outro?
Como o valor atribuido a um atributo static de uma clase pode manter um valor na memoria ate que a VM seja descarregada, onde esse valor e guardado pra que todas as classes possam ler o valor armazenado e compartilhado?
abrs
|
|
|
|
Este trecho cita também métodos private e final. E não prova nada, só diz que é mais fácil de otimizar. No máximo, será mais rápido para compilar - não é possível se basear nisso em tempo de execução.
No mais, acredito que procurar "otimizações" para uso do static seja apenas querer argumentar a favor de um design mal projetado: nada contra o uso dele, mas existem casos e casos.
Se vc pensar que todas variaveis membro declarados como static ficam carregas ate vc derrubar a VM, indica q existe um tipo de "cache estatico" na memoria, nao e?
Por isso, partindo desta ideia teriamos uma acelaraçao para os metodos static.
Nao estou considerando design e melhores praticas de refatoraçao.
Pensemos somente em velocidade de execuçao para um código!!
abrs
|
|
|
|
Acho q vcs estao em empregos muito ruins entao...
Pois so vejo aqui UK pagando de 80.000 libras pra cima... e so saber buscar, ah e claro ter um CV bom pra competir com os europeus... senao fica dificil exigir qdo se tem pouco a oferecer ne?!! 
COMO SEMPRE DIGO, QUEM GANHA POUCO NO BRAZIL, VAI CONTINUAR GANHANDO POUCO FORA DO BRAZIL!!... o mercado te escolhe, nao adianta vir com o sonho americano que estao te esperando e pagando fortunas, so pq vc veio de outro pais... Pois senao vc vai virar entregador pizza aqui, ou ate mendigo!! a vida e dura, nao adianta.
Incrivel o CWJobs.co.uk nao para de mandar vagas de 80.000 libras pra cima... e vcs dizem que nao tem? meu, vai ser ruim assim no inferno...
saudaçoes
|
|
|
|
|
|