[RESOLVIDO] Dúvida sobre desempenho

Programação Java
#1

Olá,

Pessoal, estou desenvolvendo um software que em algumas telas, como por exemplo, uma tela de cadastro de pedidos, possui muitos métodos, mas muitos mesmo.

Estava pensando em criar uma classe apenas para esses métodos, até mesmo para utilizá-los em outras telas.

Gostaria de saber se há diferença de desempenho em chamar os métodos staticamente da outra classe, ou se compensa mais deixá-los na classe original, ou seja, na classe da própria tela.

Estou com essa dúvida, porque se eu colocar esses metodos em outra classe, vou ter que passar todos os campos da tela como parametro. Se eu deixá-los na classe original eu não vou precisar passar como parametros.

Não sei se faz diferença, porém gostaria de saber a opinião de todos.

#2

Ola amigo,

Ao que parece sua questão é simples…
Não ha perda nem ganho de desempenho nesse caso pois o que se aplica nesse seu caso é o conceito da coesão…

Vc precisa refatorar sua classe que possui muitos metodos para ser mais especifica onde vc pode chamar os métodos estáticos passando um objeto como parametro…esse objeto de parametro pode ser um map Map<Object,Object> parametros=new HashMap<Object,Object>();

Nesse map vc seta seus atributos e passa para seu método de retornar algo ou não…

Não acho que vai impactar em desempenho mas vai ficar mais coeso, legivel e estético…

Fallow

#3

[color=yellow]Gambi detected[/color]

Isso não é OO!

Fazer um método estático e passar como parâmetro um hashmap<Object, Object> ?

Isso é programar estruturado em Java…
Se quiser uma dica,
Classifique novamente os comportamentos, crie os objetos necessários, os instancie e invoque os métodos :stuck_out_tongue:

Mas, respondendo sua pergunta, não, chamar métodos estáticos não tem tanto impacto no desempenho (apesar de não ser necessáriamente uma boa prática OO )

#4

Posta sua classe aí, e mostre os métodos que você quer reutilizar, que juntos a gente bola alguma coisa :smiley:

#5

Ola drigo.angelo,

Não sei c vc entendeu bem a questão ou talvez eu tb nao tenha entendido…

Ele possui uma classe que ao que parece nao está muito coesa (especifica)…

Que conceito de OO vc tem? pq no modo que está é que esta estruturado…

Aplicar o conceito da coesão é fundamental em OO… Com relação ao hashMap<Object,Object>…hum…

também poderia ser um var arg…pois depende da quantidade de parametros…

Vc prefere assinar seus métodos com n parametros? e se for necesario 20 parametros como um filtro por exemplo…? como vc assinaria? Nao é mais estético um MAP?

Fallow

#6

@paulo1911
Então, se você tiver uma classe assim, por exemplo:

public class MyClass{ public static int hello(){ System.out.println("Hello World"); //Sim, faltou criatividade, mas já serve pra ilustrar meu ponto de vista return 2; } ... }
Isso seria OO?
No meu conceito, métodos estáticos não são Orientados a Objeto, pois você não os chama a partir de um objeto

E quanto ao HashMap<Object, Object> te dou razão, quando se tem a necessidade de passar muitos parâmetros isso é útil

#7

VC está utilizando Swing?
Se for, você pode criar Actions separadas e add no componentes que deseja (por exemplo botões), só que daria um pouco de trabalho e vc teria que registrar os componentes q irá precisar realizar o gets para popular ou aplicar qualquer regra de negocio.

Agora passar um HashMap para uma classe externa, seria interessante o problema é que você teria que pegar chave e valor para popular seus objetos persistentes ou outros qualqueis, só que iria precisar de ifs, ou usar reflection para popular um entity bean por exemplo.

Você também pode deixar as ActionListeners dentro do seu form mesmo, e delegar o serviço para um objeto qualquer, mas esse objeto teria que receber todos atributos ou como Array Bruto ou como List, ou como disse antes você passaria o this do seu JForm, JPanel etc…

#8

Obrigado pelas dicas
Deu para ter uma noção de como proceder.

Achei interessante a idéia de usar o HashMap para passar os parametros. Vou tentar com ele.

Obrigado a todos

#9

Oi drigo.angelo,

Realmente seu exemplo serve para mostrar que nesse caso o método nao precisaria ser estático…

Pq ele está executando algo que nao esta relacionado ao retorno…talves…

Mas vamos olhar para as Classes Wrappers… String, Integer, Float,Double,Character etc…

O que é o método valueOf()?..não e estático…sua finalidade nao é específica? vc precisa de uma instancia de um integer para converter uma string para int?

/** Um caso Absurdo
*
*/
Integer i=new Integer("1"); // Instanciando...

int x=i.intValue(); // int é primitivo e nao aceita string... por isso precisa converter uma string em um int certo?

//Será que é necessário instanciar nesse caso de forma explicita?

/**
// Fica melhor assim!!

int i=Integer.valueOf("1").intValue();

*/

Xxx.valueOf dos Wrappers serve “especificamente para se criar um objeto e devolve-lo”

no caso do Integer.valueOf(String s) ou Double.valueOf(String);

agora o método intValue() do Wrapper Integer…precisa de uma instancia de Integer pois depende do valor contido no objeto e por isso nao poderia ser estático(e náo é mesmo)…

Na minha opiniao, métodos que não tem relacao com as variaveis de instancia (até porque static nao acessam atributos de instancia) como métodos utilitarios especificos devem ser estaticos…usar um método estático de uma classe nao é anti OO… se for assim o que seria da pratica do NumberFormat, DateFormat, Wrappers, mantendo a relacao do método com a classe em sim, como um membro dela mesmo classe(Como é definido no fundamento de static)…

No caso dos metodos utilitarios nao serem static ai sim, teria impacto no desempenho caso vc precisasse da instancia dessa classe em diverssas partes do programa…pois iria aumentar o numero de objetos no heap()…pense bem…

E se aplicando o conceito da coesão em OO, a classe utilitaria seria especifica e seus métodos independete da qntidade de parametros seriam static…

Esse é meu ponto de vista.

Fallow

#10