O ministério do desenvolvimento adverte — Desenvolver [MALANDRAMENTE] de forma anêmica causa pobreza aos seus objetos
E aweeeeeeeeeeee meu póóóvooo!!!!
Essa é a continuação do meu último post sobre arquitetura, Programação Procedural Vs. Programação Orientada a Objetos, onde já expus alguns bons pontos sobre as vantagens e benefícios da orientação a objeto.
Como tratei anteriormente, as vantagens do desenvolvimento Orientado a objeto são incríveis mediante a possibilidade de modelar um domínio de forma que este venha a representar tão bem elementos do mundo real.
Infelizmente, tal benção não é tão simples de ser alcançada e, pior ainda, grande parte dos desenvolvedores (em especial ABAPers) esperam que essa benção caia do céu.
Modelo Anêmico
O que vejo acontecendo no universo ABAP é que alguém — um troll, muito possivelmente— disse que orientação a objeto é o modo certo de desenvolvimento. E por que chamei o anunciante do caos de troll? Porque hoje o que vejo é comportamento de manada: todos dizem que Orientação a Objeto é melhor, mas poucos realmente sabem o porquê. Enquanto isso, os sistemas não param de serem desenvolvidos.
O que vejo, também, é geral experimentando e aprendendo orientação a objeto por conta própria enquanto desenvolvem sistemas alheios, isso com bases fundadas no paradigma procedural que, como também descrevi no último post, alcançou um excelente nível de recursos para modularização.
O problema do cenário descrito acima é que esse novo paradigma revolucionário funciona apenas como uma nova ferramenta para fazer a mesma coisa que já vinha sendo feita. Como é comentado por aí:
Você pode escrever FORTRAN utilizando qualquer linguagem.
Então vemos profissionais que, por se utilizar de um CREATE OBJECT no ABAP, acreditam fielmente que estão na crista da onda da orientação a objeto. E, depois de muito surfar, muito invocar CREATE OBJECTS por ai, já sentem-se confortáveis em se intitular ABAP Orientação a Objeto Expert, fazendo o código abaixo:
Este código apresentado acima é o clássico exemplo de anti-pattern que Martin Fowler batizou com o padrão Anemic Domain Model (Modelo de Domínio Anêmico).
Como descrevi acima, a ideia dessa arquitetura é justamente separar em camadas o desenvolvimento, assim tendo as regras de negócio em um canto, atributos da entidade em outro, e os acessos ao banco de dados em outro. Motivação? — Facilidade de manutenção.
O mais perigoso e traiçoeiro é que no modelo anêmico existem objetos que parecem modelar a realidade com seus VOs e BOs, mas na verdade não utilizam a característica básica de um objeto, que como descrito no meu primeiro post é:
Objeto = Estado + Comportamento
E o que são BOs e VOs?
Em uma galáxia não tão distante, a Sun lançou um catálogo de padrões chamados de Core J2EE Patterns. — E sim é uma maluquice pensar que algo de outra linguagem e que aconteceu entre o final dos anos 90 e inicio dos anos 2000 influencie nossos desenvolvimentos hoje em dia — A maior parte deste catálogo destinava a lidar com problemas do Enterprise Java Beans (EJB).
Em resumo, o EJB tinha diversos problemas e passou a ser utilizado no desenvolvimento, um modelo mais simples, quase sempre utilizando apenas Servlets ou algum framework qualquer.
Um dos padrões deste catálogo era chamado de Value Object (VO). Posteriormente este objeto foi renomeado para Transfer Object (TO) por haver um conflito de nomes dele e outro padrão, e por tratar-se de uma adaptação do padrão Data Transfer Object (DTO), também do Fowler — #zicaMemo.
O objetivo deste padrão era transportar dados entre o EJB e o cliente, o que no nosso caso acaba sendo utilizado para transportar dados entre camadas.
Business Object (BO) é um tipo de entidade perceptível sendo um ator dentro da camada de negócio. Abaixo uma representação de VOs e BOs
Mais exemplos como esse você encontra em projetos que tentam+ reproduzir o tão sonhado MVC no ABAP — e sério, toda semana recebo pedidos clamando sobre como criar uma aplicação utilizando MVC + ABAP, se você é um desses, relaxa que qualquer dia desses sai, ou não — fica aí no ar.
Com esse tipo de modelagem inicia-se os velhos problemas com includes que possuem dezenas de milhares de linhas de código, e como resultado temos as regras de negócios repetidas por estarem espalhadas por todos os quatro includes que foram criados para orientar o pobre e inocente objeto, e lá vamos nós com desafios onde:
- A coesão das classes de lógica (BOs) basicamente não existe, isso por ter que suportar diversas funções relativas não só à sua própria estrutura de dados como muitas vezes de outras;
- VOs serão utilizados apenas por um BO, adeus reusabilidade;
- Todos BOs terão conhecimento sobre a estrutura de dados (VOs), adeus encapsulamento.
Então como apontado pelo Fowler, no mundo real não existe lógica de um lado e dados de outro, é necessário ambos combinados para que seja formado um conceito.
E por essas e outras que esse tipo de arquitetura é conhecida por modelo anêmico.
Conclusão
Então chegamos a conclusão, se você é apenas como uns amigos e outros que só querem saber de [TL;DR] — Adriano Campanhola — pois bem, ao menos que você esteja criando um simples CRUD fuja do modelo anêmico.
O modelo anêmico é um modelo procedural simples que a maior vantagem ao meu ver é que maioria dos desenvolvedores facilmente entenderá, ele é engraçadinho porém vil e traiçoeiro como descrevi acima, ao invés disso estude e procure aplicar conceitos do Modelo Rico, muito discutido por um dos meus autores prediletos, Eric Evans.
Já li muitas discussões e uma em especial foi a do Greg Young que discute e apresenta recomendações da Microsoft pela utilização de modelo anêmico, isso por meio de aplicações em duas camadas com REST ou de três camadas com Web, este tipo de recomendação parece maluquice depois de tudo o que falei até aqui, mas para quem leu o livro do Fowler Patterns of Enterprise Application Architecture é possível conhecer padrões como o Transaction Script e que não é errado utiliza-los, desde que você saiba o porque e quando utilizar.
Só quem implementou uma camada de serviço sabe o desafio que é fazer isso e não cair em um modelo porco anêmico, onde o que deveria ser retornado seria um POJO, que são objetos que seguem um desenho simplificado em contraposição aos EJBs.
Mas ai você ainda está lá em cima pensando
O que é Modelo Rico?
Não esquenta não que é o tema do próximo post, até continuaria escrevendo hoje, mas já é tarde e tenho que ir embora da empresa, então até a próxima pessoal e muito obrigado por toda força que nós do Bar8 estamos recebendo.
Agora se curtiu o post não deixe de clicar no CORAÇÃO e participar comentando, pois assim você nos ajuda muito!
#Bar8Indica
Defensores do Modelo Anêmico:
