Matéria da MJ17: Desenvolvendo Sistemas OO com Padroes de Negócios

Primeira coisa gostaria de dar os parabéns ao Phillip pela matéria.

Mas como toda boa matéria ela também me deixou com algumas dúvidas:

- Um POJO precisa saber como ficar num estado consistente? Ou ele deve delegar isso a um outro objeto?

Somente exemplificando, em livros de O.O. é pregado que um objeto tem sempre que estar num estado válido e que o construtor dele deve se encarregar disso. Já pela convenção JavaBeans e até Pojos, vejo que existem brechas que *PODEm* deixar o objeto num estado inconsistente.

Pelo que entendi da matéria os objetos devem sempre estar num estado consistente e eles próprios devem se certificar de que isso aconteça.

Se sim, caso seja fornecido um argumento invalido para o construtor ou para um setter o melhor seria dar um throw numa IllegalArgumentException com uma mensagem bem animadora?

Pergunto isso, pois em vários lugares vi que POJOS praticamente não sabem o porquê vieram ao mundo, ja na matéria, pelo que entendi, os objetos sabem muito bem que espaço devem ocupar.

Desculpe se viajei muito e não entendi nada

.

Oi,

grprado wrote:Primeira coisa gostaria de dar os parabéns ao Phillip pela matéria.

Obrigado

grprado wrote:
- Um POJO precisa saber como ficar num estado consistente? Ou ele deve delegar isso a um outro objeto?

Somente exemplificando, em livros de O.O. é pregado que um objeto tem sempre que estar num estado válido e que o construtor dele deve se encarregar disso. Já pela convenção JavaBeans e até Pojos, vejo que existem brechas que *PODEm* deixar o objeto num estado inconsistente.

Pelo que entendi da matéria os objetos devem sempre estar num estado consistente e eles próprios devem se certificar de que isso aconteça.
...

Mais que POJOs, objetos de uma maneira geral devem garantir seu estado. Programar com contratos (DBC - Design by Contract) reforça isto através de algumas regras. uma pequena introdução á DBC pode ser encontrado aqui.

Note que mesmo numa linguagem totalmente integrada com DBC como Eiffel pdoe acontecer de um objeto não amnter consistência. O programador deve garantir a validade do estado do objeto. Linguagens como a citada Eiffel provêem recursos para facilitar esta verificação, em Java não tem muito jeito, é no braço mesmo.

grprado wrote:
Pergunto isso, pois em vários lugares vi que POJOS praticamente não sabem o porquê vieram ao mundo, ja na matéria, pelo que entendi, os objetos sabem muito bem que espaço devem ocupar.

O problema é que as pessoas costumam usar os chamados TO sem saber exatamente porque o fazem. Outro artigo que fala sobre isso pode ser encontrado aqui.

Muito obrigado, os artigos foram de muita valia.

Não conhecia DBC, mas já imaginava algo do tipo e que não seria muito fácil.

Quanto aos fantoches, o grande problema é que em muitos lugares eu via algo resumidamente deste tipo:

Camada de persistência retorna um pseudo-objeto (um objeto java travestido de struct, somente dados sem comportamento)
Ai a camada de negocios lida com o pseudo-objeto e vários objetos super fodões dessa camada fazem as operações de negocio e implementam externamente um compartamento interno do pseudo-objeto, por fim devolvem os dados para o usuário ou para serem persistidos novamente.

Era nesse ponto que eu me perdia, pois isso de O.O. não tem nada.

Após ler os artigos, MJ17 e do seu wiki, acredito ter encontrado um bom caminho para trilhar. Mais uma vez, obrigado.

Realmente muito legal o artigo da revista.
Parabéns!

HelloWorld Membro desde: 18/05/2006 13:09:54 Mensagens: 14 Offline

Opa, tenho uma pergunta sobre a mesma matéria, dentro do mesmo contexto.

Seguinte, no exemplo da listagem 1, tem um factory method para criar o cliente. Eu gostei muito desse approach pois caso a criação do objeto seja complexa a mesma fica bem encapsulada e cria o obj com um estado válido.

Mas como ficaria se fossem mais argumentos, ou seja, o cadastro de cliente tivesse uns 20 campos. Não da para passar String por String...

Qual seria uma forma legal de se fazer isso?

Eu pensei em algumas:

Um Hash map com os argumentos.

No caso de um app web (o meu caso) passar o form bean (Struts), ou managed bean(JSF).

Começar a criar o obj na action, a parte simples tipo setNome e etc, e passar esse quase obj para o factory method terminar o serviço.

Cada um tem sua desvantagem, falta de verificação em tempo de compilação, acoplamento, e criar um obj com estado inválido.

Qual a opinião de vocês?

[JUZAM wrote:]

Um Hash map com os argumentos.

Como vc. notou, todas têm problemas mas esta é a que eu utilizaria. Outra opção ainda é ter um construtor que receba um POJO de dados de inicialização, que, por contrato, não teria que manter nenhum tipo de consistência entre parâmetros.

De qualquer forma, acho que o problema está no requisito "objeto consistente em qualquer momento". Este requisito parece fazer todo sentido quando visto de longe, mas não sei se faz sentido mantê-lo a qualquer custo.

Na prática, creio que basta garantir a validade de invariantes em determinados momentos, em particular nos momentos em que existe efetivamente um contrato a ser obedecido, como em uma chamada de um método de negócio. AOP neste caso vem bem a calhar, pois pode ser usada para injetar a validação do estado apenas nos momentos em que isto é relevante.

psevestre wrote:AOP neste caso vem bem a calhar, pois pode ser usada para injetar a validação do estado apenas nos momentos em que isto é relevante.

O conceito de contrato implementado em Aspectos é bem útil e relevante.
Algum tempo atrás, ainda não se usava muito AOP, e fazer validações no início de métodos para verificar se um objeto veio com todos os campos necessários para realizar tal processo era entrelaçado no código, isso rolava muito no projeto na época pq haviam muitas integrações, diversos sitemas interoperando, e os contratos foram implementados na época de forma entrelaçada ...

Se fosse hoje em dia AOP era sem dúvida alguma a melhor pedida!

HelloWorld Membro desde: 18/05/2006 13:09:54 Mensagens: 14 Offline

psevestre wrote:Na prática, creio que basta garantir a validade de invariantes em determinados momentos, em particular nos momentos em que existe efetivamente um contrato a ser obedecido, como em uma chamada de um método de negócio.

Exatamente. Digamos que a invariante de um obj dependa da camada de aplicação, por exemplo, um relacionamento com um objeto proveniente da camada de persistência. Então nesse caso faz muito sentido o factory method, onde a criação ficará encapsulada em um único local.

Neste caso, acho que não faz sentido criar o objeto sem o relacionamento no managed bean, e depois enviá-lo para a camada de aplicação fazer o relacionamento.

Eu opto pelo hash map ao estilo Ruby

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

[JUZAM wrote:]Opa, tenho uma pergunta sobre a mesma matéria, dentro do mesmo contexto.

Seguinte, no exemplo da listagem 1, tem um factory method para criar o cliente. Eu gostei muito desse approach pois caso a criação do objeto seja complexa a mesma fica bem encapsulada e cria o obj com um estado válido.

Mas como ficaria se fossem mais argumentos, ou seja, o cadastro de cliente tivesse uns 20 campos. Não da para passar String por String...

Qual seria uma forma legal de se fazer isso?

Eu pensei em algumas:

Um Hash map com os argumentos.

No caso de um app web (o meu caso) passar o form bean (Struts), ou managed bean(JSF).

Começar a criar o obj na action, a parte simples tipo setNome e etc, e passar esse quase obj para o factory method terminar o serviço.

Cada um tem sua desvantagem, falta de verificação em tempo de compilação, acoplamento, e criar um obj com estado inválido.

Qual a opinião de vocês?

Acho que para criação de objetos complexos ou até povoar objetos seria interessante usar um builder!

Se alguém quiser discordar ou acrescentar algo!

É uma má idéia a camada de apresentação acessar diretamente o repository?

HelloWorld Membro desde: 18/05/2006 13:09:54 Mensagens: 14 Offline

Acredito que depende do caso.
Se for somente para montar um combo de opções, não vejo problemas.

Ou seja, não deve existir nenhuma regra de negócio envolvida.

Repositórios são objetos de domínio e anda impede que sejam manipulados pelas Camadas de Aplicação e até Apresentação.

O ponto importante é que repositórios não são DAOs, então sua Camda de Aplicação/Apresentação deve tratar Repositórios como trata (baseado no exemplo da revista) Proposta, Emprestimo, etc.

Um erro que cometi no artigo foi colocar um método salvar() no Repositório. Idealmente Repositórios devem ter uma interface parecida com a de Collections, em vez de salvar() e apagar() pense em adicionar() e remover().

Sendo assim, você poderia fazer um Service retornar um Repository. Eu não recomendo fazer este processo sem um Service porque você perde os benefícios deste ser um Façade, que incluem ter uma interface mínima. Se você expôr os métodos do Repository como interface da Camada de Negócios vai acabar com *muitos* métodos que quase nunca são usados, interfaces de Camadas em geral e Services em particular devem ter granularidade grossa.

HelloWorld Membro desde: 18/05/2006 13:09:54 Mensagens: 14 Offline

Shoes, e sobre a pergunta acima com as formas de passar os dados da camada view para a camada de serviços.

O que você acha?

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

Uma coisa que não me sinto confortavel é fazer com que objetos de negocio tenham contato com repositórios.

Será que tem uma forma boa de fazer com que objetos de negocio não tenham contato com o repositório?

Será que persistir dados é um problema de negocio???
Será que persistir dados é um problema de aplicação???

Se for de negocio justifica meus objetos de negocio terem contato com o repositorio, agora se for um problema de aplicação já não justifica muito...

Se alguém puder comentar sobre esse problema e me ajudar a refletir melhor...

abraços...

Ahhhhh Shoes parabéns pela matéria! Fowler na mente!

Repositórios não tem a ver com persistência. O fato de geralmente serem relacionados com a Camda de Persistência é um detalhe de implementação, como falei acima Repositórios não são DAOs.

Repositório é o lugar onde você acumula seus objetos, são coleções, listas.

Neste caso:

É o mesmo princípio.

O ponto é que geralmente Repositórios contêm lsitas de todos os objetos de um determinado tipo, logo dificilmente um Usuario teria um RepositorioGrupos, já que este repositório não guarda apenas os eus grupos mas todos os do sistema.

Um GerenciadorUsuario, entretanto, pode ter acesso ao repositório já que ele precisa saber onde ficam todos os grupos do sistema.

Notícias, artigos e o maior fórum brasileiro sobre Java