| Autor |
Mensagem |
|
|
Salve !
Estou projetando um sistema e me veio uma dúvida:
Tenho uma entidade Produto que representa obviamente o objeto Produto dentro do sistema. Para cada produto, poderei ter várias fotos do mesmo.
Inicialmente eu pensei em composição: ProdutoFotos (a possível entidade das fotos) é composta do Produto.
Tentativa de diagrama UML em texto wrote:Produto<>------ProdutoFoto
<>---- simbolo de composição X)
A responsabilidade de cada foto do produto seria do ProdutoFoto, e o controle sobre ProdutoFoto seria do Produto, obviamente.
Pensando um pouco mais, acho que uma solução bem mais simples, seria um vetor fotos dentro da entidade Produto mesmo.
Penso que ambas soluções seriam válidas, mas acho que a primeira - do ProdutoFotos - seria mais interessante caso eu tivesse mais coisas a gerenciar da foto, como data de adição, adicionado por quem e etc. Porém, estou pensando em adotar a solução do vetor mesmo.
O que acham ? Minha idéia está correta ou vocês vêem que isso pode não ser uma boa prática OO ?
Abraços!
|
 |
|
|
sergiotaborda wrote:Repare como vc mesmo assume que esta classe não é uma entidade. é uma "acção".
Na realidade ela está mais para serviço do que para entidade. (repare que não tem estado, e portanto não tem identidade, logo não é uma entidade).
aaah sim! Repository só aplica-se as entidades do sistema. Camadas de serviços não possui Repository ou DAO pois elas apenas executam ações para alguma entidade.
Aproveitando, deixa eu lhe perguntar: neste caso tudo bem, pois o Repository numa ação de findAll() por exemplo, retornaria uma coleção de Produto[*] para o Inventário. Mas vamos supor uma situação em que não haja uma classe de serviço para atrelar à entidade. Eu acho que ficaria estranho um objeto Pessoa receber de RepositoryPessoa uma coleção de Pessoa[*], não acha ? Como eu poderia proceder nestes casos ?
sergiotaborda wrote:Por outro lado vc está usando Inventário como uma coleção de produtos como se pode ver no main.
Na realidade vc precisa de um objeto ajudante para ser essa coleção e o inventário trabalha com essa coleção
Chamemos este objeto ajudante de ProductBag.
Com isso você sugere que nas classes de serviço eu não deva "manipular" as entidades da forma como eu fiz (criando uma coleção de Produtos) ? Elas (classe de serviço) devem sempre executar as ações e repassar o resultado, nada além disso ?
sergiotaborda wrote:Poderia, mas seria bem mais facil criar uma outra entidade (auditoriaProduto) o serviço receber o usuário e invocar o repositorio de produto normalmente, e depois o repositorio de AuditoriaProduto com referencia ao produto , usuário, data e resto dos paramentros de auditoria.
Vejamos: neste caso teriamos uma nova entidade (AuditoriaProduto), o RepositórioAuditoriaProduto e estes seriam manipulados pela camada de serviço Inventario igualmente o produto, penso. Neste caso, o serviçoInventario iria persistir o objeto no sistema e na sequência iria fazer a auditoria usando o RepositorioAuditoriaProduto.
Algo como:
Inventario#salva() --> RepositorioProduto -> Dao -> database
Inventario#salva() --> RepositorioAuditoriaProduto -> Dao(da auditoria) -> XML file
Como neste exemplo a Auditoria é uma regra para toda persistência do Produto, poderia eu deixar a implementação da entidade AuditoriaProduto a cargo da entidade Produto, não ? Funcionaria meio que uma composição. Produto morre, auditoria morre também. Parece-me lógico, o que acha ?
segiotaborda wrote:a realidade o modem é a camada de persistencia (DAO, ou DomainStore). Mas dependendo da implementação da camada de persistencia tlbv o repositorio tenha que fazer algumas tarefas como as que falei. O ideal é que ele não tenha que as fazer ( dai a importancia do DomainStore), mas caso sejam necessárias a responsabilidade é do repositorio. Básicamente, quando mais inteligente a sua camada de persistencia, menos trabalho o repositorio faz.
Certo. Entendi !
sergiotaborda wrote:Outro detalhe final. Vc ainda faz seus repositorios implementarem um interface. Entenda que a interface e a implemnetação estão fortemente acopladas. tão fortemente que nunca existirão duas classes implementando a mesma interface. Logo, a interface é ínutil. Vc pode herdar de um repositorio genérico (padrão Layer Supertype) , mas não separar interface e implementação. O repositorio tem que ser concreto ! já vimos que não faz sentido não ser concreto. Lembre-se disso. Vai poupar muita codificação desnecessária.
Pois é. Estava reparando isso enquanto montava os testes aqui. Nesses casos a interface(interface mesmo) de nada serve/ajuda no Repositório. Obrigado pelo toque !
Abraço!
|
|
|
|
sergiotaborda wrote:Exato. Repare como a herança não está de acordo com o que vc mesmo disse.
1) O repositorio é único para cada entidade. Se existem várias implementações possiveis, então não é único. Logo, o repositorio não pode ser uma interface. Tem que ser um objeto concreto ( não abstrato, não interface, não estático)
2) O repositorio comunica com um ou mais DAO. Primeiro, herança não é comunicar. Comunicar significa uma relação de cooperação (de composição). Segundo, se o DAO for a implementação de repositorio então não tem como chamar mais do que um DAO.
Acho que isto já basta para mostrar que o Repositorio é um objeto distinto do DAO. Quando digo distintio quero dizer que um não RepositoryPessoaherda ou implementa o outro. A relação é Reposiotorio--->(1...*) DAO e não Repositorio---|> DAO nem DAO---|>Repositorio
Bem, agora que você deu essa aula sobre Repository e DAO deixa eu monstrar um pequeno exemplo (agora mais real):
Entidade Pessoa:
Classe "de ação" Inventario
RepositoryInventarioImpl:
RepositoryProdutoImpl:
e a app teste...
Bom. O que acontece é o seguinte:
1. Crio alguns objetos Produtos
2. "Inicializo" o Inventario
3. Adiciono os produtos 1 a 1 no Inventario
4. Chamo o estoque.salva() que irá persistir as informações no Inventario.
Agora vem o principal:
5. No Inventario#salva é chamado o RepositoryInventarioImpl#salvar() que recebe um List com os produtos do Inventario.
6. Esse Repository por sua vez, "delega" a ação de adicionar os produtos para outro Repository (como você sugeriu (explico abaixo o por quê fiz)), o RepositoryProdutoImpl.
7. RepositoryProdutoImpl, recebe esse List e como é tarefa dele, prepara os dados para serem repassados a DAO's necessária - neste caso somente 1 DAO, a JDBCProdutoDao.
8. JDBCProdutoDao se comunica com o database via jdbc e retorna um bool que é transmitido até chegar no Inventario#salvar(), ou, em caso de exceptions, dispara a Exception e essa se propagará até a Inventario#salvar() também.
Legal, agora os motivos disto (na minha opinião e entendimento à sua explicação):
RepositoryInventarioImpl existe, pois talvez eu possa ter alguma rotina de persistência na parte de inventário, logo, eu faço uma façade da RepositoryProdutoImpl para "juntar as rotinas". Façade simples, onde não impede a comunicação direta com o RepositoryProdutoImpl. (como pede o próprio pattern).
sergiotaborda wrote:A tarefa principal de um repositorio é possibilitar que as instancias das entidades se encontrem e que os serviços encontrem as instâncias das entidades. Ou seja, ele é principalmente um "procurador" (locator). Por isso o respositorio tem um monte de métodos find. O ponto é que os métodos recebem os parametros da pesquisa e não a pesquisa em si.
Isso quer dizer que caso eu venha a ter a necessidade de persistir alguma outra informação relacionada à entidade Produtos - como o usuário que fez a alteração no estoque, criando uma espécie de log - durante um ação de salvar(), eu poderia muito bem deixar a cargo do meu RepositoryInventarioImpl receber as novas entidades (via parametros no comportamento) e cuidar de persisti-las para mim, correto ?
sergiotaborda wrote:O Repositório tem que criar um pesquisa no formato que o DAO entende (SQL para bancos, XPath para XML etc... )
Certo. Nada de mau teria caso eu repassasse o objeto Pessoa para a DAO, pois até onde sei, é na DAO que eu crio o Statement, e passo os valores usando bindParam, por exemplo.
sergiotaborda wrote:Um DAO tipicamente retorna algo semelhante a um resultSet ou a um Map. O Repositorio tem que instanciar a classe, preencher com os dados, verificar estados, etc... pode injetar objetos "filhos" etc...
Jóia. DAO retorna o renomado ResultSet para o Repositório responsável, o qual se vira para criar os objetos de retorno.
Então o Repository basicamente garante que o objeto seja "traduzido" para o idioma do banco de dados/XML/TXT, e ao mesmo tempo, "traduz" tabelas e linhas em objetos que o sistema entende. Ele é nosso tradutor, nosso modem (analogia ruim, mas vale).
sergiotaborda wrote:Mas tome atenção que o codigo salva() em pessoa não é necessário para o Repositorio.
Esse codigo em pessoa é o uso de um outro padrão (ActiveRecord).
Verdade. No ActiveRecord a implementação da persistência é feita diretamente na entidade. Já com o Repository aplicado, ele é quem cuida disto.
sergiotaborda wrote:Como a ideia é que o Repositorio funciona como uma coleção (ou seja, tem estado) vc não vai criar o respositorio cada vez que precisa dele. A sau solução foi usar static, mas isso viola o primeiro objetivo que é ter um objeto concreto e segundo, cria um "objeto global" que é sempre ruim. A solução é usar outro padrão o Registry. Este sim é um objeto com métodos só estáticos que funciona como um Map global com assinaturas especiais. Por exemplo:
huum! O Registry é o cara que "evita" que eu fique fazendo instâncias de Repositórios em todos comportamentos de persistência, como eu fiz no exemplo acima:
Ele me auxilia no "encapsulamento" dessas instâncias... seria meio que uma fábrica (factory) então ?
sergiotaborda wrote:É que com active record qualquer objeto pode mandar salvar a pessoa, mesmo quando não deveria.
O salvar é uma ação protegida por validações e outros processos do sistema que não cabem dentro do objeto pessoa ou do método salvar.
Certo. No caso, o Inventario é uma classe que apenas possui comportamentos de persistência, logo, neste caso em especifico, não há problema em trabalharmos com o salvar() nele, correto ?
Falando nisto, veja:
Antes de jogar no List mais um objeto Produto, o Inventario comunica-se com o objeto Produto que foi passado a ele para ter certeza de uma regra em espeficico. Caso, negativo nada é feito, do contrário, o produto entra na lista do Inventario.
A pergunta é: validações de regra de negócio é preferível ficar sempre no modelo, correto ? Pois uma possível implementação seria validar no RepositoryProdutoImpl, mas eu mesmo não achei muitos motivos para isto...
sergiotaborda wrote:Repito : o repositorio tem a responsabilidade de preservar os dados como e onde quiser. Ninguem pode atropelar esta responsabildiade. Outros objetos do sistema apenas podem invocar o repositorio e nunca os objetos que o repositorio usa. Isso seria uma violação grave do encapsulamento tornando o repositório de fato inutil.
Certo. Repare que no exemplo, eu mando um List de Produtos ao repositório para serem persistidos. Repare também que é o Repository quem faz a interação item a item e adiciona usando a DAO em jogo. Logo, no meu exemplo, eu não conseguiria "pular" o Repositório (algo como: Inventario -> ProdutoDAO), pois estou dependendo da interação. Por isto, estaria meu repositório executando tarefas que não é obrigação dele ? Ou seja, essa interação deveria ficar lá no Inventario#salvar(), ou o Repositório pode colocar a mão-na-massa também ?
Realmente você explicou de forma excelente ! Sem dúvidas foi bem útil para mim !
Abraços e muito obrigado ! (y)
|
|
|
|
pcalcado wrote:Sobre estes exemplos espec'ificos leia o Patterns of Enterprise Applications Architecture, de Martin Fowler.
Opa, pode deixar ! Assim que eu finalizar os Head-first que tenho aqui irei providenciar uma cópia deste do Fowler (o qual é bem falando pelo fórum ao que pude perceber)
pcalcado wrote:Usando a terminologia do artigo, DDD eh uma decisao de 3o nivel mas voce ainda esta com dificuldade no segundo nivel, portanto eh melhor se concentrar nele.
Certo !
Muito obrigado pelas dicas !
|
|
|
|
Opa,
E porque não conseguiria ? Não tenha medo, Java não morde hehe 
Comece baixando algumas apostilas que já indicaram acima e comece a ler com calma e sempre focado. Vá fazendo os exemplos e exercícios propostos. Leia artigos aqui no GUJ, do PortalJava e outros para aprender coisas novas como: Principios do Java e base em Orientação à objetos (nada profundo por hora).
Depois que souber como é a tipagem do Java, forma de funcionamento e etc., você conseguirá criar aplicações simples e conforme as dúvidas forem aparecendo, vá procurando no fórum pela resposta ou entao abra uma nova thread/tópico.
A grande sacada é: ler e codificar!
Abraço e boa sorte !
P.S: eu não fiz nem curso de lógica e tô vivinho da silva, ainda X)
|
|
|
|
rodolfomdi wrote:è...apostilas são bem vindas....mas eu já acessei este site e baixei algumas apostilas.
O que gostaria de obter é um curso...para que eu possa iniciar mais bem estruturado e posteriormente dar continuidade aos estudos.
Para vcs, estudar java sozinho é possivel, só com as apostilas???
Obrigado pela atenção!!!
Sim, perfeitamente. Só dedicar-se aos estudos, ler e principalmente realizar aplicações teste, exemplos para fixar os conhecimentos. Mais do que aprender nomes de objetos é saber quando usá-los.
Outra coisa bacana é participar de comunidades para fazer perguntas e para ajudar quem está com dificuldades em algo que você já sabe. Assim, você ajuda o cara a aprender e fixa ainda mais seu conhecimento .
Acho que o caminho é esse !
aah! Não tente ler uma apostila de 800 páginas em apenas 3 dias, pois você possivelmente não irá fixar muita coisa dela. Vá por etapas.
Abraço!
|
|
|
|
Opa!
pcalcado wrote:Acho que eh que voc^e est'a tentando aplicar uma solucao (pattern) sem entender o problema.
Na verdade estou tentando entender a solução que o Repository podem vim a ajudar a resolver. Talvez por não conhecê-la direito eu esteja direcionando de forma errada minhas perguntas/afirmações sobre. Acho que é esse o problema =/ Talvez até não tenha sentido nenhum usar Repository para um objeto Pessoa (como coloquei no exemplo lá no começo), mas realmente estou tentando entender o básico dela: o que é, para que serve como posso aplicá-la.
Verdade, eu cheguei a ler mas por cima. Li agora com mais calma e pude entender mais sobre o DDD.
(..)Using Domain-Driven Design the model expressed in software is the model that the business understands.(..)
Talvez seja esse o motivo que esteja recomendando a mim que esqueça os DDD por hora, não ?
hlegius wrote:Entendi. Nesse caso seria o básico do básico. Um objeto que comunica com JDBC para persistir e que retorna um ArrayList com os valores pesquisados e lança umas Exceptions em caso de problemas.
pcalcado wrote:nao sei se eu entendi esta frase.
Então, estava tentando dizer que o exemplo que você passou seria algo bem simples e sem preocupações com Repository, camada de persistência bem abstraída e etc.; Apenas um "corredor" entre as entidades e a camada de persistência.
pcalcado wrote:A classe ehe chamada GerenciadorXyz no exemplo porque eu nao conheco seu dominio. O importante no exemplo eh que o ' gerenciador' nao executa nenhuma regra de negocio, ele apenas executa o fluxo tira-objecto-do-banco->chama-metodo-de-negocio-no-objeto->coloca-no-banco-o-resultado-da-computacao.
Certo !
Shoes, obrigado mesmo pela ajuda e paciência !
Abraço!
|
|
|
|
pcalcado wrote:Não.
Caracas ! Ou esse pattern é muito simples e eu tô complicando ou talvez tenha que reconsiderar ir vender dog na esquina =/
pcalcado wrote:Minha sugestão é que você esqueça isso de colocar DAO (tentando sair dos nomes de DDD já que não estamos usando DDD) dentro do objeto
aaah! Pera lá. Então esse Domain-Driven Design nada mais é do que essa sopa de nomes para patterns, principios e conceitos relacionados à OO ?
pcalcado wrote:E este código é seu Façade, que é um Service Layer neste caso.
Entendi. Nesse caso seria o básico do básico. Um objeto que comunica com JDBC para persistir e que retorna um ArrayList com os valores pesquisados e lança umas Exceptions em caso de problemas.
pcalcado wrote:(..)Service Layer(..)
Como eu posso diferenciar uma façade que também exerce função de Service Layer de uma façade que é apenas uma façade ?
Aproveitando que você citou a classe GerenciadorUsuarios: é sempre preferível eu ter um objeto que manipula as entidades à que elas mesmas "se auto-manipularem", correto ? Ou seja, antes eu ter um GerenciadorUsuarios para CRUD à ter os comportamentos de persistência dentro da minha classe Usuario, por exemplo, certo ?
Abraços !
|
|
|
|
sergiotaborda,
sergiotaborda wrote:Por outro lado, qual é a responsabilidade de um DAO ?
E qual é a responsabilidade de um Reposiotorio ?
No que pude entender por nas leituras por aí, DAO seria a implementação da persistência, ou seja, o cara que salva em disco nosso objeto - ou como o Shoes disse num post: coloca-os para dormir X)
O repositório ao que entendi é uma interface dessas DAO's. Ele é único para a entidade (no exemplo Pessoa) e é ele que faz a comunicação com as DAO's existentes MySQLPessoaDAO, XMLPessoaDAO, etc.
Só que por exemplo: supondo que o objeto Pessoa ao ser persistido, necessite que: seja persistido o objeto no Database e que salve num XML, por exemplo, a hora em que ele foi persistido. São 2 rotinas: database e XML (exemplo beeem irreal, mas só pra constar mesmo). Neste caso surreal, o Repository iria servir "apenas" como uma façade para o XMLPessoaDao e JDBCPessoaDao ? Ou ele executa outra tarefa ? Veja, explico em código rapidinho:
Estaria essa idéia sobre o Repository correta, ou não tem nada a vê ? Realmente parece uma pattern simples mas digeri-la não está sendo fácil como as demais que tenho lido =~
sergiotaborda wrote:O Repositório é um objeto permite aos objetos das entidades encontrarem outros objetos de entidade. Ele são modelados como se fossem coleções de dados com métodos especiais para procurar esses dados.
Nesta sua explicação você diz que o Repositório permite uma entidade encontrar outra a qual tenha relação. Isso seria algo como: a entidade "Inventario" usa o RepositorioProdutos para localizar Produtos com certas especificações e retornar a coleção desses Produtos para ela ? OU ela usaria o RepositorioInventario e este conectaria-se às interfaces das DAO's dos Produtos para retornar um Produto[*] ?
Se for isto, a coleção seria "criada" no Repositório e devolvida já montada (num vetor, ou algo do tipo) pronto para o "Inventario", certo ? Assim eu teria que alterar somente o RepositorioProduto em caso de atualização na entidade Produto, penso.
pcalcado,
pcalcado wrote:Não apenas como esta camada funciona mas como objetos, em qualquer camada ou mesmo sem camadas, devem ser projetados.
É verdade. Eu ainda estou engatinhando nisto. Programar, programo faz um tempinho, mas aprofundar da forma correta em OO estou começando agora, por isso essa dificuldade em pegar as manhas.
pcalcado wrote:Sim mas isso não faz com que o objeto precise ter uma instância de seu repositório/DAO dentro dele. Procure ler sobre Service Layer e Façade.
Certo. Li a pattern façade e me pareceu bem simples. É uma interface que manipula outras interfaces com o objetivo de simplificar uma rotina. A grosso modo seria algo como eu ter 3 tarefas a seguir em passos, só que ao invés de chamá-las separado, posso "juntá-las" numa façade e rodar apenas um comportamento.
Assim, sendo a pattern repository aplicada como uma façade, eu teria apenas que chamá-la dentro da minha entidade usando o comportamento estático da minha Repository e ela que iria fazer o serviço sujo, apenas me retornando - ou não - algo no fim.
pcalcado wrote:Mais ou menos. Minha recomendação neste caso é que não procure entende Domain-Driven Design sem entender como criar uma aplicação Orientada a Objetos "normal" (i.e. que não usa diretamente os conceitos de DDD)
Tranquilo. Estou seguindo em partes como criar uma aplicação "OO pura" para ver e entender ela primeiro para depois entrar nas patterns mais complexas. Step by step X)
Agradeço muito a força !
Abraços!
|
|
|
|
pcalcado wrote:Por isso que eu disse: esqueça Domain-Driven Design por enquanto e se concetre em design orientado a objetos. Um repositório é algo bem diferente do que você mencionou mas acho que só é possível entender quando se entende a Camada de Negócios.
Okay! o "design orientado a objetos" que você diz é como a camada de negócios funciona ? Não entendi bem essa definição...
pcalcado wrote:Não. Um repositório é apenas onde você guarda os objetos, ele não necessariamente abstrai nada. Apesar de mais uma vez recomendar que você esqueça repositórios, um Repositório vai estar ligado com um Aggregate Root e dependendo de como você armazena seus entities e value objects ele pode ou não abstrair seus DAOs.
Sim. Depois que vi outros posts aqui no Guj onde você fala sobre a camada de negócios e sua relação com a persistência. Você falava que para a camada de negócios, uma vez em memória para sempre em memória, pois ela não "espera" que vá ser descarregada.
pcalcado wrote:Para começar, crie aplicações que possuem apenas uma Camada de Serviço usando DAOs para persistir objetos de negócio. Entender Domain-Driven Design sem experiência nisso é difícil porque quase toda a literatura foi criada para pessoas experientes.
Então você recomenda que eu foque mais na camada de negocios e seu funcionamento, e por hora persista os dados diretamente na camada de negócios ?
Agradeço as dicas. Vou atrás disso com certeza!
Abraços!
|
|
|
|
Bom... depois de procurar mais infos, montei a seguinte idéia:
Objeto Pessoa tem injetado via setter um RepositorioImpl
RepositorioImpl <implementa> Repositorio para que tal obedeça o contrato
O repositorioImpl contém as chamadas às Daos Necessárias para fazer a persistência do objeto, ou seja, se para persistir o Objeto Pessoa eu precisar de 2 tabelas distintas + umas configs no XML, eu chamaria 2 ou até 3 implementações de DAO's para que cada uma delas execute sua tarefa própria que seria mapear o objeto para um sistema relacional (database) e uma outra DAO para persistir dados no XML.
Pelo que entendi de repositório seria isto. Ele abstrai diferentes DAO's para que a entidade não saiba o que tem por trás daquele repositório.
Abraço!
|
|
|
|
truck1n,
Sua recomendação esclareceu bem a idéia ! DAO não é o fim, é um meio ao que pude entender. Com isso, após a DAO que é uma interface vem sua real implementação seja ela em JDBC, TXT, XML, enfim, a persistência "real".
pcalcado,
pcalcado wrote:Sim. Você está trabalhando com o conceito e não com a implementação, o que geralmente é algo bom.
(dica: por que você precisaria do Repositório dentro da Pessoa?)
Legal. Menos um fantasma. Mas diga-me, essa "dica" significa que não haveria motivos "reais" para uma Pessoa implementar um Repositório ? Pelo que li à fora, Repository é útil quando você tem uma entidade, no caso Pessoa, persistindo informações em diferentes DAO's uma vez que cada DAO tem a reponsabilidade de "cuidar" de um meio - database, xml, txt.. - e no caso mais especifico de db, cada DAO cuidaria de "uma tabela", correto ? Ou eu viajei demais nas leituras ? 
pcalcado wrote:Para saber mais procure sobre o padrão Registry e sobre Dependency Injection.
Eu li, na verdade passei a manhã toda lendo sobre isto e pensando em possíveis implementações. A Dependency Injection (como abrevia isto ?) pode ser implementada de várias formas: construtor, interface ou injetando via setter. Hum ! Poderia eu também implementar esse "RepositoryImpl" usando uma fábrica, não ?
Só uma coisa não bateu ainda: esse "RepositoryImpl" seria para cada entidade da aplicação, logo, eu teria que ter outra interface para ele. Resumindo: ainda é uma "sopa" para mim. Busquei alguns exemplos, porém, tá complicado digerir essa ponte entre a camada de negócio e a camada de persistência... sequer consegui implementar alguma coisinha no meu "programinha exemplo" que postei lá no começo... alguma sugestão por onde começar ?
pcalcado wrote:Dica: esqueça Domain-Driven Design por algum tempo e concentre-se em design Orientado a Objetos.
Sim. Estou tentando focar em partes para realmente entender as implementações e saber aplicar caso-a-caso, acho que com isso estou fugindo de aplicar padrões as cegas programas à fora, penso eu.
ah sim! Sobre os getters então não há pecado algum. Desde que eles não sejam inúteis, não haverá problema. (y)
Agradeço a força!
Abraços!
|
|
|
|
Salve galera !
Como alguns aqui já sabem (ou ao menos me viram no fórum nos últimos dias) estou tentando melhorar minha visão sobre OO para depois começar a me aprofundar mais em designer patters, porque senão vira uma sopa.
Então, por isto, li bastante ontem aqui no fórum e alguns blogs e sites - com destaque pro Fragmental do Phillip, o blog da Caelum e o Search do fórum.
Depois de muito ler, criei um modelo de aplicativo que simplesmente seta uns dados e "persiste-os" num possível database.
Tentei implementar: Repository, evitar os get/set burros, Dao (que não sei se seria bem esse o nome) além da Entidade. Abaixo o código:
Programa de teste
Nele eu usei o construtor da Entidade Pessoa para popular meu objeto com o nome e idade. Depois tento persisti-lo no banco de dados (que não existe) e entao pergunto ao objeto Pessoa se "ele" é maior de idade, ao invés do if(maluco.getIdade() >= 18 ) diretamente no programa teste.
A Interface
A Dao que a implementa...
e a entidade...
Agora, gostaria de tirar algumas dúvidas, se for possível...
1. A partir do momento que a "DAO" implementa o "Repository" e eu na entidade Pessoa.setRepositorio exijo que o parametro seja a Interface, eu estou "codificando para uma interface ao invés de para uma implementação" como muitos dizem ser o mais correto ?
2. no Pessoa.adiciona, eu passo para o Pessoa.setRepositorio a DAO, uma vez que não posso passar a Interface, pois ela não é algo "concreto". Essa implementação estaria correta ?
3. Quanto aos get/setters: eu usei apenas o getNome() pois no programa eu precisaria exibir o nome dele, porém não criei o getIdade. Só que ao "persistir" lá na DAO eu precisaria ter *todos* os getters para passar ao Statement do DB para ele poder gravar, além de usar *boa parte* deles para a View. Isso não seria um pecado, ou seria ?
Acho que são "apenas" estes fantasmas que rondam minha cabeça por hora. Se alguém puder comentar algo também, será de grande valia!
Abraços!
|
|
|
|
blackfalcon,
Dê uma lida na definição lá na wikipedia: http://pt.wikipedia.org/wiki/JavaBeans
Acho que ajuda a clarear tuas idéias.
|
|
|
|
Paulo e celso.martins,
Muito obrigado pelos links e comentários a respeito. Realmente abriu minha mente esses posts e wiki. Em vista disto, estou tentando adequar minhas idéias com o proposto (e correto). Gostaria aqui de colocar minha idéia rápida sobre duas classes: Produto e Pedido. Posso ? Vamos lá...
e a Pedido:
o teste:
e a saída:
Peço desculpas por não construir em Java, é que implementei em PHP para verificar a idéia dos ProdutoStatus: ISPONIVEL para verificar se rolava no php também e daí acabei por não reescrevendo a mesma app em Java... mas acho que dá para entender o funcionamento, se for o caso, reescrevo em Java, sem crises...
O que vocês acham ? Seriam uma implementação válida ou ainda tá uma programação procedural dentro de classes ?
Obrigado a todos pela ajuda =)
Abraços!
|
|
|
|
|
|