Acesso a métodos de um objeto.

JavaChild Membro desde: 30/04/2007 23:52:52 Mensagens: 130 Offline

Bom dia pessoal!

Gostaria de quando chamar um método de uma classe eu pudesse chamar sequencialmente outro método da mesma classe. (Acho que ficou um pouco confuso de entender neh xD)

Ex. Quando uso a classe Criteria do Hibernate eu posso usar assim:

Todos esses métodos que eu acessei são da mesma instância e eles sempre retornam o próprio criteria utilizado, já vi também casos que quando instancio um objeto já posso ir setando as suas propriedades chamando seus métodos´, ou seja sem utilizar o método construtor.

Ex.

Queria poder faser isso em uma classe com métodos estáticos e que se eu setar uma propriedade quando chamo um determinado método, esse método comporte-se de forma diferente.
Tudo bem que eu poderia passar valor por parâmetro, mas gostaria de implementar igual no caso do Criteria.
Esse tipo de implementação segue algum padrão ou especificação ou algo do tipo?
Como posso fazer isso?

Vlw, abraço.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

Ora, isso é muito fácil. Nunca ouviu falar de "return this"?

Em vez desse feijão-com-arroz:

use isto aqui (talvez dê até para você customizar o Eclipse 3.2 ou posterior para ele gerar os setters deste jeito, não sei):

JavaChild Membro desde: 30/04/2007 23:52:52 Mensagens: 130 Offline

puuuuutzzzz xD

nem tinha me ligado.....

vlwwwww.... abraçow

This message was edited 1 time. Last update was at 25/10/2007 12:41:53

Só de curiosidade. Essa técnica chama-se Invocation Chaining. E como this só tem sentido em objetos, não pode ser usada com métodos estáticos.

JavaChild Membro desde: 30/04/2007 23:52:52 Mensagens: 130 Offline

xD é hehe...

meu caso é justamente por ser uma classe de métodos estáticos que eu não estava conseguindo utilizar uma implementação para isso...

onde posso encontrar esses tipos de técnicas utlizadas na manipulação de objetos?

existe algo parecido quando falamos de métodos estáticos?

abraçow

This message was edited 1 time. Last update was at 25/10/2007 14:06:06

Algumas classes do Java implementam essa técnica:
ByteBuffer e StringBuilder são exemplos delas.

Eu acho muito prático também para classes matemáticas, como por exemplo, de vetores matemáticos.

Não me lembro de ver nada assim para métodos estáticos. Pelo menos, não de maneira trivial.
Aliás, na prática um bom sistema deve ter poucos métodos estáticos. Será que a tal classe não poderia ser reescrita de outra forma?

JavaChild Membro desde: 30/04/2007 23:52:52 Mensagens: 130 Offline

ViniGodoy wrote:
(...)
Aliás, na prática um bom sistema deve ter poucos métodos estáticos. Será que a tal classe não poderia ser reescrita de outra forma?

Um bom sistema deve ter poucos métodos estáticos??? Pq?

Pode sim ser reescrita.

A classe na verdade é um copy properties de um ORM para um VO, criei ela pq vi que na aplicação várias classes do nosso sistema utilizavam métodos privados para fazer a cópia de propriedades e que várias classes utilizavam os mesmos objetos.

Nessa classe que eu criei as cópias são feitas em cascata, ou seja, se dentro de um ORM tem outro ORM ele da um get e transforma também para VO, inicialmente pensei em deixar ela assim e quem quisesse fazer a cópia apenas do wrappers do ORM utilizasse o BeanUtilsBean e quem quisesse que fosse feita a cópia em modo 'cascata', utilizasse essa classe CopyProperties.

Justamente por poder ser utilizada em muitos locais diferentes e com grande frequencia pensei em utilizar métodos estáticos, a coloquei em um pacote 'util' e vários EJBs de modelo a utilizam.

Pensei em colocar uma propriedade .cascade(), assim se não fosse informado nada faria a cópia simples e se fosse chamado o tal .cascade(), faria do jeito que está hoje.

Seria melhor se estivesse de forma genérica, mas nem pensei ainda em fazer um copyProperties utilizando refletion e tals, sei lah, sempre que fiz isso achei muito lento e desempenho é um fator crítico nessa aplicação.

Na verdade esse querer implementar esse '.cascade()' é mais querer aprender do que necessidade na solução.

v1c70r_f wrote:Um bom sistema deve ter poucos métodos estáticos??? Pq?

Métodos estáticos não podem ser sobrescritos e não sofrem polimorfismo.

Por consequencia:
Não é possível fazer mocks para métodos estáticos, o que prejudica testes unitários.
Não é possível fazer proxies de métodos estáticos, o reduz possibilidades na manutenção;
Não é possível obter um comportamento polimórfico desses métodos, o que pode dificultar a implementação.
Não é possível fazer métodos estáticos com Invocation Chaining

Você pode criar uma classe com métodos não estáticos, e obte-la através de seu framework de dependency injection.

JavaChild Membro desde: 30/04/2007 23:52:52 Mensagens: 130 Offline

putz, eu fiz uma porrada de sobrecarga, e putz, a maioria das coisas que vc flw eu nem o que é pra falar a verdade....

mocks?
proxie de métodos?

carinha, agora você me deixou confuso.....

nesse caso, que implementação você sugeriria?

This message was edited 5 times. Last update was at 26/10/2007 13:55:29

Imagina a seguinte interface:

Você tem uma implementação dela assim:

Legal, não? Agora vamos supor que você precisasse gerar um log todas as vezes que esse método fosse chamado. Mas não sempre, só de vez enquanto. Aliás, só quando você (programador) fosse avaliar o seu programa. Isso não deveria ir para cliente. Como organizar a classe para isso?

Você poderia fazer um proxy. Ele implementa a interface e delega os métodos para classe principal. O proxy é possível pois ele implementa a mesma interface.

Agora, no seu código, bastaria ir na declaração da sua classe de fábrica e trocar isso:

Por isso:

Reconhece esse padrão? Se você já usou a Collections framework, já deve ter visto que é possível fazer:

O que o new Collections.unmodifiableList faz? Ele encapsula a sua lista num proxy, que lança exceção sempre que tentarem modifica-la. Ele não cria uma cópia de sua lista. A mesma coisa para o Collections.synchronizedList.

Se já usou os buffers, deve ter entrado em contato com um tipo especial de proxy, chamado Decorator. Você provavelmente tinha um InputStream bruto (como o FileInputStream). Daí, vc precisou coloca-lo num buffer para aumentar a performance. O que você fez?

E se você precisasse ler objetos lá de dentro?

Cada decorator adicionou uma pequena funcionalidade na classe original. Sacou?
Esse é o poder que você ganha com proxies.

E agora, o que é um mock? Um mock é uma classe que finge ter uma funcionalidade. É muito usado em JUnits. A grande vantagem do Mock é que vc programa ele para se comportar como você quiser.

Por exemplo, vamos supor que você esteja escrevendo um JUnit para a classe MeuObjeto. Mas a única fábrica do seu programa real é uma que pega lá do Hibernate, num servidor remoto, que está em algum lugar da web. Acho que você não gostaria de configurar um ambiente pesado como esse só para testar a classe meu objeto. Então, o que você faz? R: Um mock.

Agora você poderia implementar um JUnit facilmente:

O legal é que você poderia programar o seu Mock para gerar casos de erro. Por exemplo, para lançar a exceção de que o objeto não existe. E ver como outras classes no seu programa respondem a isso.

Por exemplo:

Note que esses métodos setFingirNaoTerObjetoNenhum e setGerarObjetosNaoIndexaveis só existem no Mock. Foram feitos especialmente para testar o Indexador e classes similares, que venham a usar a fábrica. Ele permite que coloquemos situações especiais da fábrica e testemos como os objetos (nesse caso o Indexador) devem se comportar nessas situações.

O que eu sugiro? Pense em ter uma classe concreta, sem métodos estáticos.

Agora, se o seu programa é muito simples, só para faculdade, então permaneça com os statics, pq são mais simples de implementar.

Na pressa acabei escrevendo o código da FabricaProxy ali em cima com erro.
Agora sim, dá para entender qual é a idéia do proxy.

Mais uma curiosidade. O java tem uma classe chamada Proxy, que permite a criação de proxies dinamicamente, em tempo de execução.

JavaChild Membro desde: 30/04/2007 23:52:52 Mensagens: 130 Offline

Vini, SHOW DE BOLA!

Muito obrigado pela explicação e atenção carinha!!!

Abraçooo!

JavaEvangelist Membro desde: 11/04/2006 09:35:56 Mensagens: 343 Offline

Vini, sei que o tópico é antigo, mas posso fazer uma pergunta?

Em que esse FabricaProxyComLog está ajudando o programado a realizar log apenas quando ele quer? Já que estamos instanciando um Objeto Fabrica com a implementação de FabricaProxyComLog, todas as vezes que chamarmos o método createObject o log seria realizado né não?

Abraços.

Sim. Toda vez. Mas o programa pode decidir quando usar ou não a versão com Log.

Notícias, artigos e o maior fórum brasileiro sobre Java