O que leva as pessoas a criar VOs anêmicas?

[sergiotaborda]

[quote=peczenyj]- O que leva as pessoas a criar VOs anêmicas?

A pergunta deveria ser

Quem lucra (e como) com pessoas que criam VOs anêmicas?[/quote]

Quem lucra são pessoas que dizem assim: “Classe anêmicas é sempre ruim”.
Depois criam consultorias para modificar o seu sistema para não usar classes anêmicas.
ai vc, crente de que é ruim ( ou com medo que seja ruim) contrata essas consultorias para fazer as alterações.
Depois - ou em paralelo - contrata cursos com elas para ensinarem seu staf a não usar classes anêmicas.
Como é mentira que classes anêmicas são ruins sempre o staf não compreende como o novo paradigma pode ser usado
em alguma ocasião e a consultoria é chamada de novo para resolver o problema. Afinal, o staf é uma cambada de idiotas
e as consultorias que advogam a expurgação do demônio das classe anêmica são as únicas com a verdade.

Detalhe… foram essas mesmas consultorias que criaram as classes anêmicas do sistema quando o paradigma
aceitava e até favorecia isso. É assim que se ganha dinheiro com isso. Muda-se o paradigma e refaz-se tudo de novo.
E cobra-se por isso, caro… perdão… claro.

[victorwss]

[quote=sergiotaborda]Existem mais opções que essas que considerou. Partindo agora do principio que se trata de um banco legado ( coisas que eu não parti no post anterior) vc não pode fugir do contrato que o sistema legado tem. Mas vc pode criar mediadores entre esse contrato e o contrato da sua nova aplicação.
Se o objeto original requer um raio porque é o que vai para o banco via introspecção direta do atributo ( eu tinha entendido que o FP lia o get e usada o set ) não vejo problema em criar o get/setDiametro. ( Eu tinha entendido que criar essa propriedade fazia o FP tentar ler e escrever essa propriedade no banco… se isso não acontece, não ha problema alguma)

Vc tem razão, não se pulveriza a regra, criam-se novos métodos.
[/quote]

Na verdade, eu estava falando dos dois.

Há frameworks que vão direto nos atributos.
Há frameworks que sempre usam getters e setters.
Há frameworks que não são nenhum dos dois anteriores (usam annotations, Factory Methods, ou alguma outra coisa).

Não. O que estou dizendo é que se o diametro é uma consequencia do raio, ele não é uma propriedade. No seu caso, ele é uma propriedade “paralela” ao raio. Mas sendo que o seu FP acessa os atributos diretamente os métodos que existem são irrlevantes.
Se o FP acessasse via get/set como falei ( que é o correto) a existencia de uma propriedade “virtual” como diametro causaria problemas. Mas está certo causar problemas já que ele não é uma propriedade real.

Na verdade, não vejo como a propriedade virtual possa causar problemas em um framework que trabalhe com getters e setters. A menos que ele faça algumm tipo de idiotice como ligar o nome dos getters e setters aos nomes dos campos, mas supondo que não faça isso, não vejo como poderia dar problema.

O que eu faria para resolve isso é criar um novo objeto herdado do primeiro mas com as novas propriedades ( padrão Decorator)
Para o FP eu mandava o objeto, como é da mesma classe, não teria problema, e o FP me dá o VO original o qual trasnformo no novo VO. Isso é simples se existir um camada de repositorios ou daos especificos de negocio, mas caso não exista pode, realmente, ser um problema. (é nestes casos que a gente ve se o sistema foi bem desenhado/encapsulado) Nesse caso, em que a unica alternativa é usado o VO original com novos métodos, simplesmente não usaria o get/set , faria algo como diamtero() e atribuiDiamtero() para fugir da nomenclatura. contudo isso interfere com a UI, provavelmente. Nesse caso seriam os objetos da UI a terem que ser mudados.
Fazer refactoring em sistemas legados não é fácil. as suas opções são limitadas e freqüentemente herança é a unica saida porque vc quer que o novo objeto se comporte como o velho, mas com mais alguma coisa. (padrão Decorator , Visitor e em alguns casos Proxy e Adapter)

Concordo.

Eu tinha entendido que o seu FP acessava via get/set e que isso lhe causava um problema quando adicionava o get/setDiametro.
Nesse caso o problema não era do FP e sim do contrato do seu objeto. Foi isso que tentei explicar.
Agora, se o FP acessa os atributos directamente via reflection e ignora os get/set então é o FP que está errado.

Veja, vc inclui campos privados e modificadores e acessores publicos para proteger os dados. Mas ai o seu FP viola as regras e vai direto no coração da coisa. Isso é uma violação clara do encapsulamento. Tlv vc não se importe com isso, mas mais valai os seus atributos serem simplesmente publicos e pronto: fim do problema de encapsulamento. Aceitar as duas coisas - objeto protegido e FP com reflection - não é coerente. Se vc sabe que o FP é introspectivo nos campos directamente nem precisa de set e get.

não é correto comprometer o encapsulamento em hipotese alguma. Mais vale tirá-lo do que viver em um mundo fingido de proteção. Se o FP precisa disso e não ha como alterar o FP , retire o encapsulamento em vez. O problema em legado é que a estrutrua já foi feita e se foi feita torta agora não tem como a endireitares ( não se muito esforço mental para arrajnar truques de OO que funcionam, mantem o sentido legado mas são OO)

Não. Vamos supor que o FP vá direto aos atributos. Para o FP, beleza, é como se fosse público. Mas isso não significa que eles devem ser públicos para o resto da aplicação, caso os VOs sejam reutilizados em outro ponto.

O sistema não deve ser tolerante a esse tipo de falhas porque isso é uma violação de segurança. O sistema não deve ignorar isso.
Imagine que foi alguem que entrou no banco e correu um virus que simplesmente troca o sinal de todos os numeros. O sistema não pode tolerar isso. É um desastre. é melhor que ele pare de funcionar do que funcionar errado.

Eu não disse que ele deve ignorar, mas ele não também não deve simplesmente explodir e parar de funcionar. Deve ao menos solicitar para que o usuário corrija o valor errado.

Mas ai é que está. Inválido é diferente de Incosistente. O seu objeto está consistente mesmo com valor negativo. Só que ele não está válido. O FP pode retornar objetos inválidos, o que ele não pode fazer é criar objetos inconsistentes. Se a regra no set é destinada a evitar problemas de leitura de registros com dados impossiveis, isso é consistencia e está certo que tudo dê pau e o sistema como um todo aborte. ( na real, um log é gerado e uma mensagem amigável é enviada ao usuário, o resto do sistema continua funcionando -isso é tolerancia a erro , tb)

Certo.

Vc está limitando muito as suas opções pensando assim. Vc pode simplesmente ter um construtor privado e ter métodos que lhe retorna o semaforo no estado correto( factory method) Por exemplo:

class Semaforo{

    public static Semaforo verde(){
          Semaforo  s = new Semaforo ();
          s.estado = VERDE;
           return s;
   }
  
   SemaforoEstado estado; // enum VERDE, AMARELO, VERMELHO
   private Semaforo(){}

  public SemaforoEstado  getEstado(){
        return estado;
  }

}

não ha construtor , nem set. Só um get porque a cor é uma propriedade read-only.
É com este tipo de objeto corretamente estruturado que os FP da vida têm problemas.
E eles os têm porque não permitem que factory decida como criar o objeto a partir dos dados do registro.

Excelente idéia. Porém nem o framework que trabalha com atributos e nem o que trabalha com getters e setters vão conseguir digerir isso porque o construtor sem argumentos não é público. Apenas os frameworks mais avançados vão saber lidar com isso.

O objeto NUNCA tem a validação dentro dele mesmo. Ele têm a consistência. Por exemplo, um objeto BigDecimal pode ser positivo, zero ou negativo. Ele consiste o seu estado para que assim seja. Contudo ele não sabe nada sobre validação já que isso é uma regra externa. Um objeto com a responsabilidade de validar precisa ser criado à parte.
Então, sim, vc cria outro objeto, mas não, esse objeto não é de entidade.

…

Não. Usar OO. O objeto de dados pode ter os dados que ele quiser. O objeto de validação irá validar, se esses dados, estão em conformidade para uma situação especifica. Isso normalmente inclui regras de negocio que podem até ser muito complexas.
A criação de objetos de validação em separado do objeto do dados (SoC) permite que vc escolha o algoritmo de validação e o altere sem mexer no objeto de dados (IoC). E pode até compor os validadores( composite). Assim o validador de objeto cliente é a compsição de validadores singulares para cada campo. E esses são muito reproveitáveis ( isNull, isInRange, hasSize , etc. )

É, você tem razão nestes dois pontos.

Tudo bem. Não é responsabildiade do FP validar o objeto. Se o sistema aceita que objeto seja modificado via reflection isso signfiica que qualquer coisas é um estado consistente (que é o mesmo que dizer que não ha consistencia alguma).
Vc pode resolver isso facilmente com um objeto validador para interomper as coisas se os dados não podem ser aceites.

Sim.

Não. O que eu acho é que o pessoal escolhe errado na hora de definir o que é “a lógica do objeto”.
Por exemplo, lançar métodos de crud no objeto é considerado por alguns a “lógica do objecto” quando isso não poderia ser mais contrário ao que seria a “lógica do objecto”. O exemplo bom é o BigDecimal. Vc pode usá-lo como VO e ele não contem nenhuma lógica do negocio. Contudo ele contém muita lógica do seu domínio (operações aritméticas, conversões ,etc).
Poderíamos dizer que BigDecimal é um objeto cheio de “lógica de objeto” mas vazio de "lógica de sistema"
eu acho que vc deve criar objetos ricos no sentido que eles contenham "lógicas de objeto’ e até lógica de domínio (logicas de sistema comuns a muitos sistemas) mas colocar a lógica do sistema nos objetos deve obedecer ao principio de separação de responsabilidade e isso significa que entulhar todas as logicas num objeto só tb não e´certo ( pro exemplo, colocar um metodo no usuário para validar o login e senha dele). É ai que entra a verdadeira OO , é ai que o desenvolvedor tem que mostrar porque tem esse papel e é ai que as coisas “acontecem”.
dividir as coisas entre “objetos com lógica” e “objetos sem lógica” ainda é deficiente. Isso leva à prática ( que vemos no GUJ ser referida ad naseum) de saturar o objeto com um mote de métodos de negocio. ie, um monte de responsabilidades que não lhes competem. É aqui que entra a separação clara de Entidades, Agregados, Valores e Serviços e demais objetos de aplicação com responsabilidades bem definidas. Isso é o Principio de Separação de Responsabilidade em ação.

Sim, com certeza, colocar toda a lógica é pior do que não colocar nenhuma.

Ora ai é que está. O uso de VO é legitimo. Mas como toda a legimitidade advém do consenso.
Quando à tempos atrás isso era papagaiado pela sun e todo o mundo aceitável era legitimo. Hoje com essa conversa de que objetos precisam ter lógicas ele é ilegitimo para quem pensa dessa forma.
Para mim é uma questão de contexto. Pense num webservice : nada é mais do que um grafo de VO colocado em XML e recontiuido do outro lado. Neste caso é legitimo. Imagine uma API e interface que o seu programa deixa livre para uso por scripts. Ai tb é legitimo pq vc precisa de isolamento. Quando vc trabalha em difernetes JVM mas a comunicação é interna ao ppr sistema ( por exemplo, swing acessando ejb noutr máquina) tb é legitimo. Existem muitos lugares e ocasiões em que é legitimo usar VO (atualemnte chamados TO- Transfer Objet).
Forçar que todos os objetos do seu sistema sejam “não-VO” ou “não-anémicos” também é um erro. A virtude está no meio, sendo alguns VO e outros não dependendo das suas responsabilidades.

Veja, no seu sistema de FP os seus VO têm qual responsabilidade ? Transferir dados.
Transferir dados é tão honrado quando manipular dados ou comunicar protocolos. Não ha nada de errado em que objetos tenham apenas uma responsabilidade. O desafio é que todos os objetos de todo o sistema tenham apenas uma responsabilidade.

Sim, ele é legítimo para transferir dados. O problema das arquiteturas anêmicas é usá-los também como entidade.

Ficar gritando que les deveria ter mais responsabilidade sem saber qual ela seria é vazio.

Inventar necessidades sem ter porque é uma péssima idéia em todos os casos. Não entendi o que você quis dizer com isso.

Até poderia aceitar isso se todas as outras opções falhassem, mas a minha tendencia seria usar um Decorator para não ter que fazer isso. Mas apenas se fosse realmente muito importante. ( o exemplo do diametro é um bom exemplo, mas não parece muito importante… entende?)

Sim, problemas simples devem ter soluções simples, problemas complexos talvez precisem de soluções complexas.

sim, concordo. Principalmente porque a maioria vai directo nos atributos e ignora os acessores/modificadores. (existe uma razão para se chamarem “acessores” … todo o acesso é feito por eles!)

Sim, e acrescento. Os frameworks que exigem getters e setters para tudo e morrem de forma sangrenta e dolorosa se estes não forem burros como eles esperam que são também são ruins, eles forçam você a criar o falso encapsulamento de get e set para tudo.

Ok, até aqui acho que concordamos no mais importante: O modelo anêmico tem origem na persistência e fugir disso é algo trabalhoso. O que vejo que você não concorda muito é se deve-se ou não fugir dele.

[sergiotaborda]

Na verdade, eu estava falando dos dois.

Há frameworks que vão direto nos atributos.
Há frameworks que sempre usam getters e setters.
Há frameworks que não são nenhum dos dois anteriores (usam annotations, Factory Methods, ou alguma outra coisa).

ah! bom … afinal não estou louco. … :lol: :lol:

Não. O que estou dizendo é que se o diametro é uma consequencia do raio, ele não é uma propriedade. No seu caso, ele é uma propriedade “paralela” ao raio. Mas sendo que o seu FP acessa os atributos diretamente os métodos que existem são irrlevantes.
Se o FP acessasse via get/set como falei ( que é o correto) a existencia de uma propriedade “virtual” como diametro causaria problemas. Mas está certo causar problemas já que ele não é uma propriedade real.

Na verdade, não vejo como a propriedade virtual possa causar problemas em um framework que trabalhe com getters e setters. A menos que ele faça algumm tipo de idiotice como ligar o nome dos getters e setters aos nomes dos campos, mas supondo que não faça isso, não vejo como poderia dar problema.

Sim. Supondo que o FP é dotado de mapeamento, isso não seria um problema.

não é correto comprometer o encapsulamento em hipotese alguma. Mais vale tirá-lo do que viver em um mundo fingido de proteção. Se o FP precisa disso e não ha como alterar o FP , retire o encapsulamento em vez. O problema em legado é que a estrutrua já foi feita e se foi feita torta agora não tem como a endireitares ( não se muito esforço mental para arrajnar truques de OO que funcionam, mantem o sentido legado mas são OO)

Não. Vamos supor que o FP vá direto aos atributos. Para o FP, beleza, é como se fosse público. Mas isso não significa que eles devem ser públicos para o resto da aplicação, caso os VOs sejam reutilizados em outro ponto.

Sim quer.
O objetivo se encapsular é encapsular sempre. Se existe um ponto onde não é encapsulado isso anula o encapsulamento como um todo. Logo, se a violação acontece no FP , ele pode acontecer em qualquer outro lugar ( uma violação a mais não é problema, o problema é a primeira violação).

Portanto, se vc está preocupado em encapsular no resto do sistema tb deveria estar no FP. Dois pesos e duas medidas não é coerente.

O sistema não deve ser tolerante a esse tipo de falhas porque isso é uma violação de segurança. O sistema não deve ignorar isso.
Imagine que foi alguem que entrou no banco e correu um virus que simplesmente troca o sinal de todos os numeros. O sistema não pode tolerar isso. É um desastre. é melhor que ele pare de funcionar do que funcionar errado.

Eu não disse que ele deve ignorar, mas ele não também não deve simplesmente explodir e parar de funcionar. Deve ao menos solicitar para que o usuário corrija o valor errado.

Mas ai que tá. O FP é um cara lá na ultima camada. ele não pode fazer isso que está pedindo. O máximo que ele pode fazer é lançar exceções que as camadas acima possam interpretar e levar à correção.

não ha construtor , nem set. Só um get porque a cor é uma propriedade read-only.
É com este tipo de objeto corretamente estruturado que os FP da vida têm problemas.
E eles os têm porque não permitem que factory decida como criar o objeto a partir dos dados do registro.

Excelente idéia. Porém nem o framework que trabalha com atributos e nem o que trabalha com getters e setters vão conseguir digerir isso porque o construtor sem argumentos não é público. Apenas os frameworks mais avançados vão saber lidar com isso.

Ora ai está. Esse são ainda são escassos.

Ora ai é que está. O uso de VO é legitimo. Mas como toda a legimitidade advém do consenso.

Sim, ele é legítimo para transferir dados. O problema das arquiteturas anêmicas é usá-los também como entidade.

Será mesmo isso ?
Quanto a mim não. Qaundo o Fowler se queixou do anemismo era porque os objetos não tinham lógicas relativas a eles mesmos - não ao sistema. O caso clássico é o calculo da idade em que o objeto mantêm a data de nascimento mas não sabe calcular idades. Então o calculo é espalhado pelo resto do código.
Até ha quem coloque isso num objeto Utils da vida, mas isso não resolve. O ponto é deixar o calculo da idade junto com o dado que define a idade. Isso torno o seu objeto de dados menos anêmico na perspectiva do Fowler, mas continua não o tornando uma entidade.
Quando vc pensa dessa forma vc descobre rapidamente que objetos especiais tem metodos especiais e recorrentes. Conta sempre tem saldo, mas o objeto Conta não tem um método saldo(). É isso que é o problema. Logicas que dizem respeito ao proprio objeto e que levam a codigos assim:

em vez de :

Isto é muiiiito difernete de codigos que extrapolam as responsabilidades como por exemplo

Que mata o sistema por muito fluente que pareça.

Então, é bom sublinhar o que significa ser anêmico: significa não ter consigo os métodos que dizem respeito (*) a si mesmo.
Isso é muito diferente de ter qualquer método anexado a si.

(*) Que são da responsabilidade de.

Ficar gritando que les deveria ter mais responsabilidade sem saber qual ela seria é vazio.

Inventar necessidades sem ter porque é uma péssima idéia em todos os casos. Não entendi o que você quis dizer com isso.

O quiz dizer é que não vale a pena fazer alarde que anêmico é ruim quando “anêmico” não está bem definido. Isso so atrapalha.
dizer “Esse seu objeto não faz nada. jogue um métodos ai” é inútil Nem todos os objetos aceitam métodos especiais.

[quote]
Ok, até aqui acho que concordamos no mais importante: O modelo anêmico tem origem na persistência e fugir disso é algo trabalhoso. O que vejo que você não concorda muito é se deve-se ou não fugir dele.[/quote]

Não acho que o modelo anêmico tenha origem na persistência embora, possa , até, concordar que o framework que usa na persistencia influencia bastante o modelo de dados. Eu acho que ele tem origem em falhas de modelagem por decisões erradas
dos desenvolvedores. O banco é um espectador ( exceto quando é legado) logo a responsabilidade recai no desenvolvedor que aceitou um codigo espalhado ( codigo esparguete). O problema real é se ele teve escolha. Se ele vez um modelo anemico mas não tinah escolha não ha realmente culpa, mas se ele pode escolher e escolher errado, ai sim ele tem que ser responsabilizado por um codigo ruim.

Não vejo o TO com maus olhos já que todos os objetos de entidade , são, por construção, TO.
Eles podem até ter uma logica a mais, mas essas logicas aparecem normalmente em objetos de valor como implementações de Money. Para entidades puras ( Pedido, Cliente, etc…) os métodos especiais são mais relativos a relacionamentos, mas podem ser realmente mais espertos como Conta.getSaldo(Date.today())). Só que essa esperteza tem um outro preço que escapa da conversa dos modelos anêmicos que passa pelo design da estrutura interna desses objetos e do ambiente onde eles vivem. Vc onsegue garantir que conta.getSaldo() funciona em qualquer ponto do sistema , mesmo quando o sistema é distribuído ? Garantir isso não é fácil. E é essa dificuldade que leva à criação dos Busines Objects, porque é mais facil.

Portanto, tudo se reduz à dificuldade em implementar um modelo denso e complexo de entidades de forma e performance ótima.