Killing the getter´s and setter´s

Nao eh soh importante seguir os padroes, como eh ESSENCIAL seguir a nomenclatura de getters e setters se vc for usar coisas como o java.beans.Introspector e afins (que eh o que o Hibernate, Struts, WebWork e amigos usam). A menos que voce esteja afim de testar os limites do codigo dos outros provendo BeanInfo...

Ninguém usa BeanInfo's... N.I.N.G.U.E.M
Ou seja, ou segue a nomenclatura, ou tá perdido.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Esse é o principal impecilio para deixar de usar getters e setters.
Que Mer.......

This message was edited 1 time. Last update was at 25/09/2009 14:53:25

ressuscitando tópico...

Pessoal nosso amigo Sabella comenta:

Mas aprendi que colocar lógica de negócio fora dos objetos é uma grande cagada, obviamente, tudo tem exceções. No princípio não parece, mas depois vai doer, acredite

existe um artigo do Calçado: http://fragmental.com.br/wiki/index.php?title=Fantoches, no qual ele diz:

Você geralmente acaba com uma serie de classes (geralmente implementando o padrão Command induzido pelos Frameworks MVC web, mas por vezes são Façades) coordenadoras e um bando de objetos burros que nada mais são que um agrupamento de dados relacionados.

se n me engano, o livro java efetivo tambem diz algo a respeito.

oque entendi disso tudo e que presensio é que a maioria dos sistemas possuem objetos apenas com seus dados e os getters e setters. Oque é "terrivel", uma vez que pode-se mudar o estado de um objeto tornando-o inconsistente sem contar que toda a logica de negocios fica numa classe manipuladora desse objeto, logo a logica nao pode ser reaproveitada.

Postando na pratica:

ESTRUTURADO:

struct de luxo

classe de negocios

beleza, funciona, porem fica estruturado, sem contar que alguem em algum lugar do codigo pode fazer:

e esquecer de setar a data criando assim um objeto num estado invalido.

o certo seria colocar o comportamento dentro do proprio chamado e nao fazer o setter:

Prezados amigos, entendi certo ou "viajei na maionese" ? rsrsrs

Outra pergunta, o que fazer quando frameworks exigem os getters e setters ?

grande abrasssssss

JavaEvangelist Membro desde: 02/05/2006 15:30:50 Mensagens: 475 Offline

Também sou da mesma opnião de que o autor cria interfaces desnecessárias. Image isso em uma sistema de 100 tabelas no banco e consequentemente teremos 100 classes. Usando a abordagem do autor não teria como você usar o framework por exemplo que depende dos getters e setters, ou qualquer outro que dependa.
Acho o seguinte que devemos ter estes atributos somente onde é necessário

JavaEvangelist Membro desde: 26/02/2007 09:31:49 Mensagens: 329 Offline

Não sou a favor de criar get e sets a "rodo" tb, mais frameworks principalmente web que utilizam eles como padrão, o jsf por exemplo, exigem o get e set "public" por exemplo, e isso faz com que entidades que são utilizadas na view tenham get e set.

Nota: O hibernate não força o uso de get e set. Ele utiliza instrospecção e reflection se não me engano.

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