Comments on: Objetos não são atributos + funções

By: Falhas no ensino de Orientação a Objetos « DevBlogs

Falhas no ensino de Orientação a Objetos « DevBlogs — Sun, 29 Jun 2008 12:30:58 +0000

[...] post Objetos não são atributos + funções o autor apresenta de uma forma bastante humorada os grandes problemas do ensino da Orientação a [...]

By: Fluent Interface « Meu manifesto!

Fluent Interface « Meu manifesto! — Mon, 16 Jun 2008 03:37:36 +0000

[...] Não devemos pensar em uma classe como uma mera coleção de atributos. Objetos também não são atributos mais funções, e sim estado + comportamento. O Phillip Calçado explica muito bem isso! Refatorando a linha 2 [...]

By: Phillip Calçado

Phillip Calçado — Wed, 28 May 2008 13:24:45 +0000

@Anderson

Orientação a Objetos em si não fala de sistemas distribuídos, ou persistência, ou segurança, ou qualquer coisa parecida. Dado isso você tem que pensar que não pode expôr objetos, tem que expôr componentes.

EJBs, em chamadas remotas, são componentes e não objetos.

By: Anderson

Anderson — Wed, 28 May 2008 13:15:27 +0000

Shoes, concordo que os objetos precisam ter dados + comportamento. Mas fico um pouco confuso na hora de projetar sistemas distribuídos. Como fica esta arquitetura em um sistema distribuído, com EJB’s, com um framework como o JBoss Seam, onde o objeto praticamente só tem dados e o comportamento e as regras de negócio ficam no Session Bean, como um Business Object?

By: Fragmental » Blog Archive » Nem só de troca de mensagens vivem os objetos

Sat, 24 May 2008 17:06:53 +0000

[...] que boa parte das dúvidas quanto ao meu post sobre como objetos não possuem atributos se deve ao fato das pessoas não terem geralmente um conhecimento real sobre o que é troca de [...]

By: Objetos = estado + comportamentos « TJRN Developers

Objetos = estado + comportamentos « TJRN Developers — Thu, 22 May 2008 23:40:57 +0000

[...] Objetos = estado + comportamentos Postado no 22, Maio, 2008 de samuelvalerio OO de verdade! [...]

By: Diego Carrion

Diego Carrion — Wed, 21 May 2008 12:19:54 +0000

Acho que entendi Shoes, obrigado pela explicação, ao parecer eu estava modelando de mais.

De qualquer modo se um dia desses você fizer um post mais detalhado sobre esse assunto acho que seria muito legal.

Ate mais.

By: Phillip Calçado

Phillip Calçado — Tue, 20 May 2008 23:10:19 +0000

Diego,

Antes de mais nada este tópico não é sobre Domain-Driven Design, mas ainda que fosse você precisa identificar o que é domínio e o que é processo atual. O objetivo de DDD ou OO não é modelar o mundo exatamente como ele é e sim modelar o domínio, o que é algo bem diferente.

No domínio todas as inormações que dizem se o pedido foi cancelado ou não estão dentro dele mesmo. O pedido não pensa e nem a pessoa neste caso. O pedido contêm a informação necessária, a pessoa apenas olha o pedido e te dá a informação dele.

A maioria dos papéis “burros” como olhar para uma folha de papel e ver se tem um carimbo REJEITADO não é modelada diretamente, apenas as tomadas de decisão. O papel da “pessoa que te diz isso” não é exercido por uma classe que extrai essa informação e sim por um intermediário como uma interface gráfica que exibe o status do pedido.

Ainda assim, mesmo que você resolva modelar o papel das “pessoas” no processo como classes (fugindo de DDD) isso não te impede de usar objetos que recebem mensagens.

By: Diego Carrion

Diego Carrion — Tue, 20 May 2008 21:27:57 +0000

Então Diogo, desde o meu ponto de vista, uma classe como Pedido somente deveria ter getters e setters. Como o Shoes diz, uma classe representa estado + comportamento, so que um pedido não tem comportamento. O pedido não se mexe, não cresce, não fala, não pensa, etc.

Na vida real você não pergunta para o pedido se ele é válido ou não. Na vida real você pergunta para uma pessoa com o conhecimento do dominio se tal pedido é válido ou não. Sendo aquela afirmação verdadeira, por que no sistema teria que ser diferente? Não é o objetivo do DDD representar o dominio na vida real no desenho do software?

By: Diogo Souza

Diogo Souza — Tue, 20 May 2008 00:12:13 +0000

Mais um ótimo post Shoes! Aprendendo muito cada vez que leio seu blog.

@Diego
Se eu entendi alguma coisa, um pedido define seu estado pelos seus próprios atributos(incluindo agregações), se estes atributos são preenchidos do banco de dados ou de web services é responsabilidade da camada que lhe retorna este objeto “preenchido”(dao?).

No modelo/negócio, o isFinalizado() verifica seus atributos e checa se esta tudo OK. Esta é a lógica do negócio que este modelo(Pedido) representa, veja que este não cuida de buscar os dados, apenas de trabalha-los.

Bom… é assim que eu entendi.