| Autor |
Mensagem |
|
|
Tá legal. O título ficou super estranho, mas calma, eu explico !
Papo é o seguinte: olhei aqui no fórum um tópico que fala sobre o Javabeans e tem um um wiki na wikipedia falando sobre também.
Pelo que entendi, basicamente ele tem os getters e setters da entidade com um construtor vazio. Algo como:
Só que a minha dúvida é mais pro lado de OO do que outra coisa. Para esse Bean, eu tenho uma "classe" de ação, como por exemplo uma classe Inventario, logo, a Inventario.adiciona() aceitaria esse Bean Produto como parametro e por este motivo a Inventario.listar() retornaria uma coleção de Produto[*] (beans).
Até aqui tudo legal, só que pensem comigo: quando eu vou numa loja comprar um produto eu não "entrego" um "objeto" Produto para receber os produtos que casam com meus critérios, eu passo "especificações" e daí sim o Inventario me retorna objetos Produto[*], certo ?
Logo, penso que se Produto é um "objeto" real do produto que estou indicado, eu teria que ter uma classe ProdutoSpec para indicar nela os atributos que eu possa usar como referência para pesquisa como nome ou validade, e alguns outros como o "codigo" diretamente no Bean Produto.
Ou será que estou complicando algo que é simples ? 
Se alguém puder me dar uma iluminada aí, ficaria grato !
Abraços!
|
 |
|
|
tarcisio.filo,
Certo. É realmente tem sentido a disponibilidade não ser atrelada à agenda. Eu poderia na rotina de agendamento delegar para a Disponibilidade a tarefa de verificar se o horário está disponível, acho que seria uma solução. Haveria um contato (troca de informações) entre Agendamento e Disponibilidade, mas elas estariam meio que "livres" uma da outra.
Veja, tentei especificar no diagrama minha idéia com as dicas do tarcisio.filo em relação ao Agendamento:
Se eu precisasse puxar algum agendamento do Médico, alimentaria a AgendamentoSpec e essa seria a chave para carregar o objeto Agenda que me retornaria objetos Agendamento com os horários encontrados. Penso que faça sentido, mas gostaria da opinião da galera por aqui 
Pensei em algo similar na Disponibilidade. Irei pensar para ver se sai algo
Agradeço a força 
Abraço!
|
|
|
|
Salve turma. Já apareci aqui algumas vezes sapiando os posts, mas acho que chegou a hora de participar efetivamente do ambiente, se é que me permitem
bom, vamos lá... estava eu aqui pensando em um probleminha na modelagem dos meus objetos, e daí resolvi perguntar a opinião dos senhores, para talvez me indicar algo.
Tudo começa com um Médico. Ele é uma classe no meu sistema, isto é fato. Só que ele pode manipular sua agenda de atendimentos aos pacientes (outra classe). Legal, só que daí temos:
Ele entra com os dias e horas que irá atender pacientes (disponibilidade). Com isto fechado, ele poderá criar agendamentos para atender os pacientes somente dentro desses dias/horários.
Pensando uma arquitetura correta, eu penso que teria:
classe Agenda que irá controlar as adições/alterações na agenda (seja disponibilidade, seja agendamentos).
classe Disponibilidade para armazenar informações sobre as disponibilidades dele.
classe Agendamento para armazenar as informações sobre so agendamentos dele.
Parece meio óbvio, porém, nesse modelo eu tenho a classe Agenda executando mais de uma ação (gerenciar ações das Disponibilidades e ações dos Agendamentos).
Eu havia pensado em trabalhar diretamente com os objetos, tipo, ações de disponibilidade na Disponibilidade, e o mesmo no Agendamento, entretanto me pareceu estranho eu buscar as disponibilidades do Médico usando o objeto Disponibilidade e retornar um List de Disponibilidade. Afinal eu não entrego um "objeto Disponibilidade" para receber a lista de disponibilidade dele, entrego especificações - por isso eu tenho a classe DisponibilidadeSpec que trata disso para mim.
O que vocês acham ? Trabalhar centrado na classe Agenda e esta retornar objeto Disponibilidade ou/e Agendamento dependendo do caso ? Se for, penso que eu teria que abstrair algo na classe Agenda para evitar que ela faça duas funções (o que é totalmente pecado em OO).
abraços!
|
|
|
|
peczenyj wrote:Veja bem, se vc tivesse apenas um atributo e um valor, tudo bem, mas vc tem varios, isso 'implica' em ter uma coleção e uma relação entre um atributo e um valor. Poderia ser um hashtable, como algo mais elaborado.
Vish enrolou hehehe...
Deixa eu entender:
Você sugere que eu una as classes AtributosProdutos e AtributosValor, reduzindo a uma so classe, a AtributosProdutos. Essa AtributosProdutos controlaria o tipo (color, size) e o valor (azul, branco, pequeno). Isso confere ?
Partindo disto, vem o modo de funcionamento dessa AtributosProdutos. Eu imaginei por Arrays, pois não tenho uma "hashtable" aqui (é em PHP o sistema =]) mas fico imaginando que seria meio inviável pois eu teria que ter várias instancias de AtributosProdutos em Produtos para setar cor tamanho largura, confere ?
Por fim vem o tipo de relaciomento entre AtributosProdutos e Produtos. AtributosProdutos não existe sem um Produto, logo é composição, confere novamente ?
Obrigado pelas dicas 
|
|
|
|
peczenyj wrote:Essa relação é muito estranha pois vc pode ter 5 atributos e 3 valores.
Entendo.
Pensei em três classes pois posso ter:
Cor: Azul, verde, vermelho
Tamanho: pequeno, médio, grande, 12cm, 20cm ..
Mesmo assim você acha que posso jogar essa AtributosValor para AtributosProduto que daria certo ?
Pelo que entendi você sugere que eu jogue como chave sendo a "cor" e o valor "azul", por exemplo, seria isso ou entendi errado ?
E neste caso, seria relacionamento do tipo Agregação, correto ?
Agradeço a ajuda =)
|
|
|
|
Pessoal,
Gostaria de uma ajuda num problema aqui:
Tenho o cenário:
Produto
AtributoProduto
AtributoValor
Produto: é uma classe de produtos normal.
AtributoProduto: é uma classe que contém os atributos do Produto. Ou seja ele armazena as palavras: "Cor", "Largura", "Altura" e etc.
AtributoValor: é o cara que tem o valor dos AtributosProduto. Seguindo o exemplo acima teriamos: "Azul", "12cm", "15cm" e etc.
Uma relação válida seria:
Produto: Caixa
--
Atributo1: Largura
AtributoValor1: 12cm
--
Atributo2: Cor
AtributoValor2: Azul
--
Atributo3: Altura
AtributoValor3: 12cm
Eu só não poderia ter duas alturas em um mesmo produto por exemplo. Mas atributos diferentes no mesmo produto, sim.
Inicialmente eu preciso das três classes (acho).
Pensei em Composição, pois um Atributo só existe se houver Produtos. Mas não dá certo porque tem uma terceira classe que tem os valores (a AtributosValor) que é dependente da AtributosProdutos.
Isso já foi o necessário para me dar um nó =(
Alguém tem alguma dica ?
Abraço!
|
|
|
|
|
|