Probleminha OOAD (DDD Repositórios)

Debugger Membro desde: 28/09/2006 15:51:27 Mensagens: 59 Offline

Ops, desculpe .. o objetivo são os quartos disponveis e não indisponíveis.

Debugger Membro desde: 28/09/2006 15:51:27 Mensagens: 59 Offline

Eu acredito que realmente pelo fato de eu querer os quartos disponíveis por periodo eu teria que saber das reservas os quartos reservados e por consequência trazer do repoistorio dos quartos os que não estão reservados. axo que precisariamos mais que um unico local.

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3009 Offline

eu me referi a manutensão do quarto... não vejo problema em delegar para o quarto saber se ele esta disponivel ou não... não importando o que lhe torne indisponivel... penso da seguinte forma... se o quarto não sabe se ele esta disponivel ou não... se quem sabe isto e a reserva... se surge um elemento diferente da reserva?

no caso delegando a responsabilidade para a reserva como vc resolveria então se um dia seu cliente coloque um terceiro fator que indisponibiliza o quarto? diferente da reserva? como manutenção, interditação, limpeza ou outro fator que não seja a reserva?

sobre este diagrama:

vendo que ambas as classes tem os periodos em comum... sujeria colocar uma interface Periodo onde qualquer elemento que possa inviabilizar um quarto implemente e esta interface faça sua agregação com o quarto... e não 2 classes identicas como na figura... assim não gera dependencias desnecessarias... apenas tera uma dependencia com uma interface e não se importaremos com quem a implemente...

HelloWorld Membro desde: 19/06/2008 16:05:49 Mensagens: 10 Offline

Só uma sugestão: que tal trocar TodosQuartos.getDisponiveis(periodo) por TodosQuartos.disponiveisEm(periodo) ?
Nomes são importantes. E se a língua escolhida para nomear as coisas for o português, provavelmete não existirá esse 'get' na linguagem do domínio.

JWizard Membro desde: 18/02/2008 16:17:53 Mensagens: 2981 Offline

Documento de Visão wrote:4. A reserva é associar um período de tempo a um quarto, se uma pessoa quiser mais de um quarto são consideradas duas reservas; O sistema deve impedir reservas duplicadas de quartos em um mesmo período;

23. O hóspede pode prorrogar a sua estadia, mas se existir reservas para o quarto que ele está, deve-se verificar a possibilidade de transferir a reserva para outro quarto de mesma classificação. Se a transferência não for possível, deve-se oferecer um quarto de classificação maior ao hóspede (nesse caso, o hospede seria transferido e uma nova reserva criada). Somente em último caso deve-se negar a prorrogação, porém, as reservas feitas com antecedência devem sempre ser respeitadas;

Reservas já são associações de quartos com períodos, e a reserva é o componente crítico da disponibilidade dos quartos. O repositório Reservas é que responde por essa lista.

Mesmo se escolhêssemos a opção 1, ela ainda teria que consultar as Reservas. Escolheria a opção 2 também para evitar duplicação da responsabilidade, ou delegação desnecessária.

This message was edited 1 time. Last update was at 12/08/2009 15:26:30

luistiagos, colocar mais requisitos vai mudar o problema, e com isso a discussão como um todo. Como falei, vamos esquecer essa questão manutenção de quartos e outros. Há outras maneiras de colocar mais requisitos e gerar as mudanças que provem qualquer ponto de vista. Vamos nos ater somente a Quartos e Reservas. OK? (de qualquer forma, não vejo a sua sugestão como melhor opção, podemos discutir depois).

Atentem o seguinte: A disponibilidade do quarto é temporal. A questão não é simplesmente "o quarto saber se ele está ocupado ou não". A questão é: "na data xx/xx/xxxx o quarto está ocupado?". Isso tem relação com quartos ou com reservas?

This message was edited 1 time. Last update was at 12/08/2009 15:30:02

É, até seria plausível o quarto ter um atributo "disponivel". Agora quem disponibiliza ou não disponibiliza, por quanto tempo, etc. é onde está o porém.

This message was edited 1 time. Last update was at 12/08/2009 15:41:31

Bom, como já disseram, internamente o repositório de quartos poderia usar o repositório de reservas para definir quais os disponíveis, já que todos pertencem ao domínio. No caso poderia ser uma implementação tipo a do bruno77sa, mas sem usar um service e usando o que o viniciusv colocou:

No caso de ter que lidar com outros tipos de indisponibilidade, bastaria trabalhar este método. Mas mesmo levando em conta apenas os requisitos colocados eu ainda deixaria a responsabilidade com o repositório de quartos. Mas é apenas minha opinião! (por enquanto)

Essa discussão tá bem interessante!

This message was edited 2 times. Last update was at 12/08/2009 15:45:53

Err... vocês não acham isso um pouco estranho não?

(depois me falam que a UML não serve para nada)

rodrigoy wrote:A questão é: "na data xx/xx/xxxx o quarto está ocupado?". Isso tem relação com quartos ou com reservas?

Ainda continuo indicando as reservas para tomar conta disto.

flws

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3009 Offline

rodrigoy wrote:luistiagos, colocar mais requisitos vai mudar o problema, e com isso a discussão como um todo. Como falei, vamos esquecer essa questão manutenção de quartos e outros. Há outras maneiras de colocar mais requisitos e gerar as mudanças que provem qualquer ponto de vista. Vamos nos ater somente a Quartos e Reservas. OK? (de qualquer forma, não vejo a sua sugestão como melhor opção, podemos discutir depois).

Atentem o seguinte: A disponibilidade do quarto é temporal. A questão não é simplesmente "o quarto saber se ele está ocupado ou não". A questão é: "na data xx/xx/xxxx o quarto está ocupado?". Isso tem relação com quartos ou com reservas?

certamente a questão temporal tem a ver com as reservas...
bem qual a melhor solução do problema então?

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3009 Offline

viniciusv wrote:Só uma sugestão: que tal trocar TodosQuartos.getDisponiveis(periodo) por TodosQuartos.disponiveisEm(periodo) ?
Nomes são importantes. E se a língua escolhida para nomear as coisas for o português, provavelmete não existirá esse 'get' na linguagem do domínio.

Por padrão na nomeclatura da propria sun e aconselhavel usar getters e setters... talvez vc pense que isto e uma tremanda de uma bobagem... porem se for usar reflection para automatizar um pouco as coisas precisara de td em um padrão... dai sim vc vai ver a verdadeira utilidade de padrão para nomeclaturas...

GUJ Ranger Membro desde: 11/05/2007 19:46:22 Mensagens: 817 Offline

rodrigoy wrote:Err... vocês não acham isso um pouco estranho não?
(...)

Acho que temos um impasse aqui:

Existem razões técnicas para achar que o repositório de reservas é o melhor lugar para obter essa informação (pelo fato de as reservas conhecerem os quartos e não o contrário). Porém, por outro lado, colocar isso no repositório de quartos é muito muito muito MUIIIITO mais intuitivo.

luistiagos wrote:

viniciusv wrote:Só uma sugestão: que tal trocar TodosQuartos.getDisponiveis(periodo) por TodosQuartos.disponiveisEm(periodo) ?
Nomes são importantes. E se a língua escolhida para nomear as coisas for o português, provavelmete não existirá esse 'get' na linguagem do domínio.

Por padrão na nomeclatura da propria sun e aconselhavel usar getters e setters... talvez vc pense que isto e uma tremanda de uma bobagem... porem se for usar reflection para automatizar um pouco as coisas precisara de td em um padrão... dai sim vc vai ver a verdadeira utilidade de padrão para nomeclaturas...

Concordo em parte com vc. Já trabalhei num código no qual precisei usar reflection e tive que seguir alguns padrões sim. E se vc for chamar esse método em uma expressão EL ou algo parecido será de fato ruim. Mas, pra começar a implementar o domínio acho que a idéia do viniciusv de dar mais expressividade é boa. Se depois aparecem limitações tecnológicas então terá que refatorar.
E rodrigoy: desculpe fugir do tema!

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