Modelos Anemicos

03/02/2016

0

Sei que deve ser um assunto bastante avançado, mas me desculpem, não entendi a praticidade do conceito de "Modelos Anêmicos", pode me ajudar, esclarecendo.

Agradeço.
Eduardo Pessoa

Eduardo Pessoa

Responder

Posts

03/02/2016

Edson Venancio

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.
Responder

03/02/2016

Eduardo Pessoa

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

04/02/2016

Jothaz

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:

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;
    }
}
Responder

04/02/2016

Edson Venancio

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
Responder

04/02/2016

Edson Venancio

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 ?
Responder

04/02/2016

Jothaz

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.
Responder

04/02/2016

Edson Venancio

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..
Responder

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.
Responder

04/02/2016

Eduardo Pessoa

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)?
Responder

04/02/2016

Marcos P

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.
Responder

04/02/2016

Eduardo Pessoa

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

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 }.
Responder

04/02/2016

Eduardo Pessoa

Sim, sim, claro.
Responder

04/02/2016

Eduardo Pessoa

Sim, sim, claro.
Responder

05/02/2016

Roseane Silva

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

Que tal ter acesso a um e-book gratuito que vai te ajudar muito nesse momento decisivo?

Ver ebook

Recomendado pra quem ainda não iniciou o estudos.

Eu quero
Ver ebook

Recomendado para quem está passando por dificuldades nessa etapa inicial

Eu quero

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar