Modelos Anemicos
03/02/2016
0
Agradeço.
Eduardo Pessoa
Posts
03/02/2016
Edson Venancio
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.
03/02/2016
Eduardo Pessoa
04/02/2016
Jothaz
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:
public class Carro { private int _posicaoAtual; public void Andar() { this._posicaoAtual += 10; } }
Anêmico:
public class Carro { private int _posicaoAtual; public int PosicaoAtual { get{ return this._posicaoAtual;} set{ this._posicaoAtual = value;} } } public class BLCarro { publicvoid Andar(Carro carro) { carro.PosicaoAtual += 10; } }
04/02/2016
Edson Venancio
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
04/02/2016
Edson Venancio
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 ?
04/02/2016
Jothaz
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.
04/02/2016
Edson Venancio
Como voce disse jothaz independente da maneira em programar , o certo e fazer de maneira correta..
04/02/2016
Marcos P
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.
04/02/2016
Eduardo Pessoa
04/02/2016
Marcos P
04/02/2016
Eduardo Pessoa
04/02/2016
Marcos P
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.
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 }.
05/02/2016
Roseane Silva
Clique aqui para fazer login e interagir na Comunidade :)