Esta classe seria um modelo anêmico?

Programação Arquitetura
#1

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

#2

[quote=danielbussade]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 [/quote]

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?

#3

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

#4

[quote=victorwss]
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?[/quote]

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

#5

[quote=chicobento][quote=victorwss]
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?[/quote]

Pq tipo primitivo não pode ser null, e para certos sistemas, null é diferente de 0.
[/quote][quote=http://www.hibernate.org/116.html]

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.[/quote]

Como muita gente usa Hibernate…

#6

[quote=rafaelglauber][quote=chicobento][quote=victorwss]
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?[/quote]

Pq tipo primitivo não pode ser null, e para certos sistemas, null é diferente de 0.
[/quote][quote=http://www.hibernate.org/116.html]

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.[/quote]

Como muita gente usa Hibernate…[/quote]

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!!

#7

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.

#8

Com JDBC vc ainda tem o mesmo problema…

#9

[quote=chicobento]Com JDBC vc ainda tem o mesmo problema…

[/quote]

Não.
Leia isso

#10

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

EDIT: já esculhambamos a thread…foi mau!

#11

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

EDIT: já esculhambamos a thread…foi mau! [/quote]

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

Att

#12

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.

#13

[quote=chicobento][quote=victorwss]
Não.
Leia isso
[/quote]
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.
[/quote]

int x = rs.getInt(1);
minhaEntidade.setValorInteger(rs.wasNull() ? null : x);

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.

#14

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

EDIT: já esculhambamos a thread…foi mau! [/quote]

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

Att[/quote]

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

#15

[quote=victorwss][quote=chicobento]Com JDBC vc ainda tem o mesmo problema…

[/quote]

Não.
Leia isso

[/quote]

Gambiarra.

Fora que SQL já é uma gambiarra.

#16

[quote=Bruno Laturner][quote=victorwss][quote=chicobento]Com JDBC vc ainda tem o mesmo problema…

[/quote]

Não.
Leia isso

[/quote]

Gambiarra.

Fora que SQL já é uma gambiarra.[/quote]

Porque SQL é gambiarra??

#17

Porque ainda tem gente que acha que SGBD’s são uma tecnologia não-madura, que nunca vai emplacar e acreditam no coelhinho da páscoa.

Sinceramente, acredito mais na possibilidade de ORM ser uma gambiarra do que SQL (Eu amo ORM, diga-se de passagem).

Não dá pra simplesmente jogar fora anos de pesquisa e maturação. Algumas coisas vc usa (Query’s malucas pra tirar o relatório que o chefe pediu pra ontem), outras vc coloca na prateleira e diz o quanto já te foi útil (Struts 1.x)

:mrgreen:

Desculpem o tom irônico, aprendi essa lição da pior forma possível… Não desprezar o que o mercado usa… Não desprezar o que o mercado usa…
e principalmente, não cuspa em uma tecnologia, pode ser que ela encha sua orelha de grana amanhã.

#18

Voltando a pergunta inicial sobre o modelo anêmico.

Não dá para afirmar se sua classe é anêmica ou não uma vez que os métodos estão omitidos. O que faz uma classe anêmica é definir na classe seus dados mas não seu comportamento:

[quote=Fowler]
“The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. What’s worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.” http://www.martinfowler.com/bliki/AnemicDomainModel.html [/quote]

Algumas classes são anêmicas por natureza, isso não é probelma, o anti-pattern mora no coração daquelas que possuem comportamentos mas estes não são refletidos em sua implementação.

#19

[quote=qmx]Porque ainda tem gente que acha que SGBD’s são uma tecnologia não-madura, que nunca vai emplacar e acreditam no coelhinho da páscoa.

Sinceramente, acredito mais na possibilidade de ORM ser uma gambiarra do que SQL (Eu amo ORM, diga-se de passagem).

Não dá pra simplesmente jogar fora anos de pesquisa e maturação. Algumas coisas vc usa (Query’s malucas pra tirar o relatório que o chefe pediu pra ontem), outras vc coloca na prateleira e diz o quanto já te foi útil (Struts 1.x)

:mrgreen:

Desculpem o tom irônico, aprendi essa lição da pior forma possível… Não desprezar o que o mercado usa… Não desprezar o que o mercado usa…
e principalmente, não cuspa em uma tecnologia, pode ser que ela encha sua orelha de grana amanhã.[/quote]

Não tenho nada contra SGBDs, aliás a teoria dos conjuntos e a relacional são umas das mais úteis no campo da matemática aplicada. Tem lugar garantido.

Só tenho muita coisa contra SQL(e DDL):

[list][] é a linguagem padronizada com mais implementações não-padrão que existe;
[]qualquer coisa fora de CRUD de uma tabela só é um horror para montar;
[*] e que ela é uma linguagem humanizada demais, sendo que seus clientes principais são programas de computador, e dá-lhe horas gastas traduzindo um modelo p/ outro.[/list]

[size=7](Off: este software jforum tb é outra porc…)[/size]

#20

[quote=Alessandro Lazarotti]Voltando a pergunta inicial sobre o modelo anêmico.

Não dá para afirmar se sua classe é anêmica ou não uma vez que os métodos estão omitidos. O que faz uma classe anêmica é definir na classe seus dados mas não seu comportamento:

Então lezinho eu perguntei justamente se ela se caracteriza uma classe anêmica porque só tem um metodo que tenha regra de negócio que o metodo getTotalPedido(), os outros são todos definidos no construtor.

Gostaria de saber se essa eh uma abordagem correta, se não quais são as outras alternativas, e se isso faz dessa classe um modelo anêmico.

Valeu