Modelos Anemicos

Eu entendi como um anti pattern, pois o mesmo foge da arquitetura em camadas, a camada de modelo, a camada de regras de negócio, e a camada de acesso a dados.

Tipo pelo que entendi voce usa um modelo anemico é o mesmo que voce fazer crud sem , usa DAO, BO, DTO..

Por exemplo , coloca instruções sql que poderiam esta presente em uma classe DAO, junto com os codigo de interface grafica ao fazer cruds..

Só o que acho, vamos ver o ponto de vista de outras pessoas.

Edson, pode até ser isso que descreveu mas vamos aguardar mais pessoas. Agora não entendi o motivo de fazer sem os padrões.

O entendimento do Edson Rodrigo esta no caminho certo, vou só tentar contribuir com mais um ponto de vista. E é um assunto que daria um artigo, portanto complicado para ser abordado em um post.

Martin Fowler considera Modelo Anêmico anti pattern, mas já vi outras opiniões que o consideram um design pattern válido, não vou entra nesta ceara, cada uma abstraia como achar melhor.

O "Modelo de Domínio Anêmico" Anemic Domain Model, é usado no desenvolvimento de software baseado no domínio do negócio, e seus objetos que representam modelagem do negócio são "anêmicos",porque são desprovidos de comportamento.

Sendo Ogro o Modelo Anêmico seria como usar OO pensando procedural. Isto acontece por exemplo com o conceito de responsividade, joga-se o bootstrap no projeto, mas para criar-se o lay out usa-se table. E o que é pior isto é bem comum;

Na verdade nos primórdios do desenvolvimento do OO como tudo era novidade, então era usual fazer-se uso deste modelo. Até hoje acontece muito dessas misturas de conceito por falta de conhecimento ou mesmo por deslumbramento. O camarada aprende a criar "getters e setters" e já se acha doutor em OO.

Outro ponto de muita confusão e confundir modelo em camadas (3-Tier) com padrões de projeto (design pattern).

O problema do Modelo Anêmico é justamente contradizer os principio básicos do paradigma de OO, pois possui códigos duplicados na camada de acesso a dados, reduz o acoplamento/coesão entre os componentes de acesso a dados e o modelo de domínio do aplicativo e abstrai a maneira como o código de acesso de dados é escrito em suas aplicações.

Muitas vezes o projeto utiliza-se de 3 camadas, mas por desconhecimento implementa o Modelo Anêmico

Se você quer mesmo pensar em design e arquitetura é aconselhável substituir o Modelo Anêmico pelo Modelo Rico, onde usa-se todo a arsenal da OO, tais como: herança, reutilização, polimorfismo, nível mais elevado de abstração, encapsulamento, utilização de um único padrão conceitual e etc.

Um exemplo clássico para ver a diferença entre Modelo Anêmico e Modelo Rico seria modelar um carro:

Modelo Rico:



Anêmico:

Abri um post no guj sobre o assunto, teve uma resposta semelhante a sua tambem Jothaz..

Resposta do Outro Forum:
Então.. Modelo Anêmico é muitoo discutido.. Você vai achar várias opiniões, mas a sua principal tese é: tenha camadas separadas: negócio, modelo, etc.. Ou seja, sua Entidade Pessoa com seus getters e setters e sua camada DAO acessando os dados da Pessoa. Isso é o modelo anêmico.

Por quê ele é dito como um anti-pattern? Pois, foge do conceito de Orientação a Objetos (OO). Ao utilizar a entidade Pessoa somente para getter e setter, você perde toda riqueza de OO: polimorfismo, herança, encapsulamento, etc..
Por que?? Pois, sua entidade é "magrinha", ela mal faz nada, só representa um Objeto, nada mais. Daí a expressão "Anêmica".
O correto seria torná-la rica: faça a Pessoa manipular seus atributos e não outras classes. A Pessoa deve ser a única a conhecer de seus atributos e seu comportamento. Faça o uso de herança, polimorfismo e abstrações..
Fonte:
http://blog.caelum.com.br/o-que-e-modelo-anemico-e-por-que-fugir-dele/ http://www.martinfowler.com/bliki/AnemicDomainModel.html

Acho que é meio complicado o programador se ater a todos os detalhes de Orientação a objetos, principalmente quem trabalha como freelance , que agilidade e enconomia de tempo é uma das prioridades..

E tambem ate quem trabalha muito em equipe deve fica dificil, pois um ou outro na equipe leva a serio a forma correta de usar a orientação a objetos, creio que isso leva ate a uma certa discursao entre os participantes de determinados projetos..

Voce que é experiente Jothaz, ja presenciou algo semelhante ?

Pois é o assunto é polêmico e muito sutil. A grosso modo no Modelo Anêmico esta tudo lá, só que não da melhor forma. E no inicio era ensinado assim.

Acho que o problema é que a esmagadora maioria dos profissionais não fazem ideia da abrangência da OO. Aqui mesmo no fórum 90% não sabem quase nada ou sabem o básico do básico. Eu mesmo que já trabalho a muito tempo com OO e muitas vezes acho que não sei nada, pois é abstrato e abrangente. Pois todo dia aprendo uma coisa nova.

Outro detalhe é de que a maioria dos desenvolvedores usam Modelos Anêmicos e nem se dão conta disso.

Em um projeto quanto mais pessoas participam, mais probabilidade de que o caos se instale. Muitas vezes para um torre de Babel, pois cada um fala um idioma diferente. Por isto a importância de se gerar artefatos claros para nortear o desenvolvimento, tais como: documento de arquitetura, guia de design, guia suplementar, casos de uso, diagramas e etc. Quanto mais claro como o processo deva serja implementado melhor. Mas mesmo assim estamos lidando com pessoas e isto normalmente fode tudo. Quanto maior o projeto mais difícil manter um padrão e a qualidade e ovelhas desgarradas sempre surgem.

Trabalhei em um projeto em que tínhamos: projetista, arquiteto, especialistas em UML, especialista em requisitos, dba, analista de sistemas e desenvolvedores. E usávamos a Suite Rational Rose. Então com esta infra conseguimos manter tudo nos conformes. Pois timanhos ferramentas da Rational como Requisit Pro, Clear Case e etc. Assim era criado ao caos de uso, modelado UML, criado os diagramas, o projetista enviava os métodos com a assinatura e o desenvolvedor implementava.

Agora na maioria dos projetos por falta de tempo ou mesmo por preguiça a coisas é tocada mais nas coxas. Acho que dependendo do cenário não temos como fugir, mas importante saber fazer a parada da forma correta. O problema é que criar um design e arquitetura profissional é trabalhoso e exigem muito conhecimento.

A tecnologia avança muito rapido , nao da pra domina tudo ou se preocupa nesses detalhes, quando se é cobrado agilidade e entrega de software em prazo.
Como voce disse jothaz independente da maneira em programar , o certo e fazer de maneira correta..

Modelo anêmico é aquele em que as classes tornam-se simples descritivos e depósitos de dados !

Os conceitos básicos de O.O., principalmente encapsulamento e polimorfismo, permitem que as classe incorporem comportamentos ( ou regras de negócio ).

Quando isso não ocorre, de maneira generalizada na aplicação, temos um modelo anêmico, onde grande parte das regras de negócio está na implementação ( usualmente, procedural ) e não nos objetos instanciados.

Passei um tempinho para ler tudo! A grosso modo e "ogramente" falando, o modelo anêmico é desenvolvido na pratica em sistemas comerciais(venda de software, projetos)?

Modelo anêmico é uma má prática na implementação de sistemas orientados a objetos, ou seja, uma falha no uso dos conceitos desse tipo de programação.

É uma falha? Como assim? Agora está ficando complicado.

Um implementação rica de programação orientada a objeto, prevê que seja criados métodos que implementem comportamento ( regras de negócio ) nas classes.

Se isso não ocorre, temos uma sub-utilização da orientação a objetos. Aliás, o termo anêmico, lembra isso : { adjetivo - que sofre de anemia }.

Sim, sim, claro.

Sim, sim, claro.

Nunca ouvi falar sobre esses modelos, pelo que me recordo não vi em nenhuma apostila alem de não ser visto facilmente.