Esta classe seria um modelo anêmico ?

Olá a todos do GUJ, há um tempo atrás estava desenvolvendo em conjunto com um amigo, um sistema de E-commerce, percebi que em muitas classes tinha um "que" de modelos anêmicos, por exemplo a classe PedidoVenda abaixo.

A maioria dos campos, são inseridos diretamente pelo construtor, ou seja como os pedidos nao podem ser editados, esta classe eh uma classe imutável, eu nao precisarei de getters e setters, não só esta classe mas algumas outras são definidas assim.
Este tipo de classe seria um "modelo anêmico", é correto este tipo de programação??

Gostaria de opiniões sobre o assunto!

Att

danielbussade wrote:Olá a todos do GUJ, há um tempo atrás estava desenvolvendo em conjunto com um amigo, um sistema de E-commerce, percebi que em muitas classes tinha um "que" de modelos anêmicos, por exemplo a classe PedidoVenda abaixo.

public class PedidoVenda { private KeyPedidoVenda keyPedidoVenda; private Date dataPedido; private String observacao; private String status; private Float total; private Boolean entregueAoCliente; private Boolean montagem; private Double totalBruto; private Double valorDesconto; private Boolean entregaDomicilio; private Float valorFrete; private CondicaoPagamentoVenda condicaoPagamentoVenda; private Cliente cliente; private Endereco endereco; private String keyBoleto; private List<ItemPedidoVenda> itens; private String ipCompra; private Date da; private String obsCancelamento; private String nomeFormaDeEnvio; private Integer qItem; private String idVendedor; private String tid; }

A maioria dos campos, são inseridos diretamente pelo construtor, ou seja como os pedidos nao podem ser editados, esta classe eh uma classe imutável, eu nao precisarei de getters e setters, não só esta classe mas algumas outras são definidas assim.
Este tipo de classe seria um "modelo anêmico", é correto este tipo de programação??

Gostaria de opiniões sobre o assunto!

Att

Pelo que você descreveu, não, não é anêmica. Saber se é o jeito correto? Seria necessário você descrever mais a fundo o sistema. Mas só o fato de você ter pensado em imutabilidade já mostra que possivelmente você está fazendo a coisa certa.

Mas, me faz lembrar de uma outra questão bem diferente... Quem foi que inventou a idéia (ao meu ver absurda, mas posso estar errado), de que classes de entidades não podem ter atributos de tipos primitivos?

Então vitor, obrigado pela resposta, antigamente quando comecei a programar em java, a primeira coisa que fazia nas classes depois de definir os atributos era o Eclipse mandar gerar todos getters e setters, só que como você mesmo observou em outro tópico , isso apenas cria um falso encapsulamento, já que o getter e setters nao fazem nada mais, não há nenhuma regra de negócio envolvida.

Então hoje so defino getter e setter no que realmente há necessidade, quando não há regra nehuma, coloco ele direto no construtor, não sei se isso é correto se não for queria saber outra forma de fazer.

Valeu

victorwss wrote:
Mas, me faz lembrar de uma outra questão bem diferente... Quem foi que inventou a idéia (ao meu ver absurda, mas posso estar errado), de que classes de entidades não podem ter atributos de tipos primitivos?

Pq tipo primitivo não pode ser null, e para certos sistemas, null é diferente de 0.

chicobento wrote:

victorwss wrote:
Mas, me faz lembrar de uma outra questão bem diferente... Quem foi que inventou a idéia (ao meu ver absurda, mas posso estar errado), de que classes de entidades não podem ter atributos de tipos primitivos?

Pq tipo primitivo não pode ser null, e para certos sistemas, null é diferente de 0.

http://www.hibernate.org/116.html wrote:

Hibernate throws a PropertyAccessException or NullPointerException when I load or query an object!

A PropertyAccessException often occurs when the object being passed to the setter method is of the wrong type. Check your type mappings for the offending property. (To see exactly which property was the problem, you might need to disable the CGLIB reflection optimizer.) However, the most common cause of this problem is that Hibernate attempted to assign null to a property of primitive type.

If your object has a primitive-type property mapped to a nullable database column then you will need to use a Hibernate custom type to assign a sensible default (primitive) value for the case of a null column value. A better solution is usually to use a wrapper type for the Java property.

Como muita gente usa Hibernate.....

This message was edited 1 time. Last update was at 18/09/2008 13:52:26

rafaelglauber wrote:

chicobento wrote:

victorwss wrote:
Mas, me faz lembrar de uma outra questão bem diferente... Quem foi que inventou a idéia (ao meu ver absurda, mas posso estar errado), de que classes de entidades não podem ter atributos de tipos primitivos?

Pq tipo primitivo não pode ser null, e para certos sistemas, null é diferente de 0.

http://www.hibernate.org/116.html wrote:

Hibernate throws a PropertyAccessException or NullPointerException when I load or query an object!

A PropertyAccessException often occurs when the object being passed to the setter method is of the wrong type. Check your type mappings for the offending property. (To see exactly which property was the problem, you might need to disable the CGLIB reflection optimizer.) However, the most common cause of this problem is that Hibernate attempted to assign null to a property of primitive type.

If your object has a primitive-type property mapped to a nullable database column then you will need to use a Hibernate custom type to assign a sensible default (primitive) value for the case of a null column value. A better solution is usually to use a wrapper type for the Java property.

Como muita gente usa Hibernate.....

Concordo com você, mas também não podemos transforma isso em regra neh , porque tem muita gente que ainda usa JDBC na mão!!

This message was edited 1 time. Last update was at 18/09/2008 14:02:56

E se a coluna para a qual ela mapeia for NotNull? E se for intencional o comportamento 0 = null?

Uma coisa que eu acho particularmente irritante é o uso do Boolean no lugar de boolean. Isso porque Boolean tem 3 estados e não 2 (true, false e null). E 95% das vezes que aparece o valor null, eu gostaria que ele fosse tratado como false, mas quando vem o Boolean eu sou obrigado a trabalhar com uma lógica booleana de três estados e ficar cabreiro com NullPointerExceptions.

EDIT: E não é certo (em um modelo de orientação a objetos pura e perfeita) quebrar a modelagem de suas classes por conta de limitações de frameworks.

Com JDBC vc ainda tem o mesmo problema...

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html#getInt(int) wrote:
Returns:
the column value; if the value is SQL NULL, the value returned is 0

This message was edited 1 time. Last update was at 18/09/2008 14:04:49

chicobento wrote:Com JDBC vc ainda tem o mesmo problema...

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html#getInt(int) wrote:
Returns:
the column value; if the value is SQL NULL, the value returned is 0

Não.
Leia isso

This message was edited 1 time. Last update was at 18/09/2008 14:10:57

Concordo com você, mas também não podemos transforma isso em regra neh , porque tem muita gente que ainda usa JDBC na mão!!

regra não é...só dei um exemplo por que o povo fala tanto isso...

EDIT: já esculhambamos a thread...foi mau!

rafaelglauber wrote:

Concordo com você, mas também não podemos transforma isso em regra neh , porque tem muita gente que ainda usa JDBC na mão!!

regra não é...só dei um exemplo por que o povo fala tanto isso...

EDIT: já esculhambamos a thread...foi mau!

É verdade a thread começou com uma pergunta e depois partimos para outra dúvida, mas isso é normal

Att

victorwss wrote:
Não.
Leia isso

Tudo bem, parabéns, vc conseguiu descobrir que essa coluna erra null e populou seu atributo como 0. Agora, imagina que na tela por exemplo, vc precisa diferenciar se era 0 ou null. Ou você usa a regra da inferência de que 0 == null, ou você adiciona outro atributo na sua classe dizendo que o valor daquele campo era null.
Não vamos desvirtuar, acho que você já entendeu que essa idéia não é tão absurda assim como vc pensava anteriormente.

chicobento wrote:

victorwss wrote:
Não.
Leia isso

Tudo bem, parabéns, vc conseguiu descobrir que essa coluna erra null e populou seu atributo como 0. Agora, imagina que na tela por exemplo, vc precisa diferenciar se era 0 ou null. Ou você usa a regra da inferência de que 0 == null, ou você adiciona outro atributo na sua classe dizendo que o valor daquele campo era null.
Não vamos desvirtuar, acho que você já entendeu que essa idéia não é tão absurda assim como vc pensava anteriormente.

Onde você precisa saber se era nulo usa uma classe empacotadora. Onde nulos não fazem sentido, usa primitivo. Eu não disse para usar primitivo sempre, apenas não concordo com a idéia de usar empacotadoras sempre.

danielbussade wrote:

rafaelglauber wrote:

Concordo com você, mas também não podemos transforma isso em regra neh , porque tem muita gente que ainda usa JDBC na mão!!

regra não é...só dei um exemplo por que o povo fala tanto isso...

EDIT: já esculhambamos a thread...foi mau!

É verdade a thread começou com uma pergunta e depois partimos para outra dúvida, mas isso é normal

Att

Isso é fácil. Quando um tópico desvirtua para uma coisa, basta desvirtuar esta outra coisa novamente de volta para a pergunta original.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Online

victorwss wrote:

chicobento wrote:Com JDBC vc ainda tem o mesmo problema...

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html#getInt(int) wrote:
Returns:
the column value; if the value is SQL NULL, the value returned is 0

Não.
Leia isso

Gambiarra.

Fora que SQL já é uma gambiarra.

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