Motivado pelo post do Paulo sobre repositórios aqui no GUJ, quero fazer uma pergunta para saber a opinião e para vocês refletirem.
Imagine que você está fazendo um sistema de hotel (que é o estudo de caso do nosso curso OOAD com UML2. Se quiser, veja o documento de visão linkado (não é necessário ler o documento todo, mas quem tiver curiosidade em ver a “big picture”)
Num determinado ponto do sistema há o seguinte requisito:
Ao efetuar a reserva o sistema deverá exibir uma lista de quartos disponíveis para o período da estadia do hóspede.
Pergunta: Quem responde pela lista de quartos disponíveis para o período?
Pois julgo ser responsabilidade do quarto saber se ele está ocupado.
Parece mais intuitivo ler o código: TodosQuartos.getDisponiveis do que TodasReservas.getQuartosDisponiveis.
Se você tiver que procurar no sistema aonde está a regra para exibir os quartos disponíveis, minha primeira tentativa seria procurar algo relacionado com quarto, e não com reserva.
Quando está reservado, lógico! Veja que a pergunta é quartos disponíveis no período. Se há uma reserva futura para o quarto ele está reservado para aquele período.
Opção 1. O repositório TodasReservas poderia ter um método como getQuartosReservados(periodo):Quartos mas não getQuartosDisponiveis(periodo):Quartos. Apesar de ter exceções, como no exemplo do seu post (Yoshima), a regra 1 repository para cada aggregate está resolvendo a maioria dos meus problemas.
eu não faria em nenhum repositorio apresentado, porque este requisito não esta em nenhum deles, veja:
1-O repostorio de quartos, representa uma colecao de quartos, pelo requisitos apresentados o que define se esta reservado ou não é a relacao de agregacao entre o mesmo e sua reserva, ou seja aqui não é o lugar, aqui só tenho minha caixa de quartos, não tenho informacão sobre reservas aqui.
2-daria pra fazer no repositorio de reservas, mas a ideia deste objeto no sistema seria representar apenas os quartos com reserva no periodo, e para atender esse requisito o repositorio de reservas deveria saber sobre todos os quartos, o que acredito que não seja o intuito do mesmo.
e agora? como resolver?
Service!!!
public class ServiceReservas{
public getQuartosDisponiveis(periodo):Quartos{
Set todosQuartos = TodosQuartos.getTodosQuartos(); //nome tosco eu sei :)
Set quartosReservados = TodasReservas.getQuartos(periodo); //reserva so vê quartos reservados, ou pelo menos deveria!!
Set quartosDisponiveis = todosQuartos.removeAll(quartosReservados);
return quartosDisponiveis;
}
}
outra versão!!
public class ServiceReservas{
public getQuartosDisponiveis(periodo):Quartos{
Set todosQuartos = Quartos.getTodos();
Set quartosReservados = Reservas.getQuartosReservados(periodo);
Set quartosDisponiveis = todosQuartos.removeAll(quartosReservados);
return quartosDisponiveis;
}
}
vamos as observacões
obs:1 desconsiderem esse meu codigo java, ha 3 anos que não mexo no bichinho,sei que tem erro ai!!
obs:2 desconsiderem os nomes dos metodos, pensei rapido aqui!!
obs:3 meu teclado disconfigurou aqui linux,por isso engoli os acentos!
bem essa é minha visão, eu faria desta forma, o que achas?
Eu acho que fica mais coerente TodosQuartos.getDisponiveis, opção 1.
Mas:
Qual a diferença? :? [/quote]
Nesse caso acho que ele quis dizer que TodasReservas deve conhecer quartos relacionados a elas, as reservas. Portanto, apenas os quartos reservados. Mas, no fundo se vc sabe todos os reservados para um período, a principio, os que sobram são os disponíveis. Embora isso possa não ser de todo verdade, pois podem haver outras formas de se indisponibilizar um quarto além da reserva, como colocá-lo em manutenção ou interditá-lo talvez.
[quote=MarceloAraujo]Não tem essa opção, mas…pq não hotel.getQuartosDisponiveis(periodo):Quartos ?
Parece ser mais coerente com o negócio e também com a OO.[/quote]
Marcelo, se você for nessa linha de pensamento um monte de coisas irão ser questionada para o Hotel. E outra: Já parou para pensar que isso é um Singleton? Quem dá a instância de Hotel?
Hotel é o domínio que estou modelando. Neste caso, me é estranho ter um elemento Hotel dentro do domínio Hotel.
A Reserva depende de Quarto independente de Quartos estarem reservados ou não. Porém, quartos não sabem da existência de reservas.
Service é transacional e sua execução tem efeito colateral, o que não acontece com o requisito solicitado. É só uma busca por informações. Você está modelando um novo repositório com nome de service.
Nesse caso acho que ele quis dizer que TodasReservas deve conhecer quartos relacionados a elas, as reservas. Portanto, apenas os quartos reservados. Mas, no fundo se vc sabe todos os reservados para um período, a principio, os que sobram são os disponíveis. [/quote]
Seu raciocínio está certo. No último diagrama que postei fica claro que reservas sabem da existência de quartos. A associação deixa a dependência explícita. O contrário é que não é verdade. Quartos não dependem de reserva.
[quote=FredMP]
Embora isso possa não ser de todo verdade, pois podem haver outras formas de se indisponibilizar um quarto além da reserva, como colocá-lo em manutenção ou interditá-lo talvez.[/quote]
Isso não está nos requisitos!
[piadinha](cada dia que passa eu vejo que não é o cliente que aumenta o escopo… são os programadores…) [/piada]
[quote=FredMP]
Embora isso possa não ser de todo verdade, pois podem haver outras formas de se indisponibilizar um quarto além da reserva, como colocá-lo em manutenção ou interditá-lo talvez.[/quote]
Isso não está nos requisitos![/quote]
Acredite… esse requisito irá aparecer logo logo! :twisted:
[quote=rodrigoy][quote=MarceloAraujo]Não tem essa opção, mas…pq não hotel.getQuartosDisponiveis(periodo):Quartos ?
Parece ser mais coerente com o negócio e também com a OO.[/quote]
Marcelo, se você for nessa linha de pensamento um monte de coisas irão ser questionada para o Hotel. E outra: Já parou para pensar que isso é um Singleton? Quem dá a instância de Hotel?
Hotel é o domínio que estou modelando. Neste caso, me é estranho ter um elemento Hotel dentro do domínio Hotel.[/quote]
Ok. A minha intenção foi dizer q nenhum dos 2 repositórios parece ser o responsável por responder quais quartos estão disponíveis num período de tempo. Isso partindo do princípio que vão existir os 2 repositórios que você mencionou e que TodosQuartos conhece apenas os Quartos que o hotel tem e TodasReservas conhece apenas Reservas e seus respectivos Quartos reservados.
Faz sentido todasReservas saber algo sobre os quartos q não estão reservados, num determinado período de tempo?
Ou então todosQuartos saber algo sobre período de tempo, que é uma característica de reserva?
Sendo assim você vai precisar de alguém que assuma a responsabilidade de subtrair os "“quartos reservados para o período informado”, da “listagem geral de quartos do hotel” e com isso ter em mãos a lista de quartos disponíveis para o período. Ou seja, alguém que tenha acesso aos 2 repositórios que você criou ou alguém que assuma a responsabilidade de lidar com os dois domínios (Reserva e Quarto) quando eles estão associados e também quando não estão.
Imaginemos como isso seria feito manualmente: um quadro na parede com vários quadradinhos, cada um representando um quarto existente no hotel. Em cada quadradinho, haveria 3 informações básicas: o número do quarto, o tipo (simplesinho, fodão, mais ou menos) e o preço da diária.
|||||||
|||||||
|||||||
Beleza, agora imagine que quando alguém vai lá e pede pra reservar o quarto, a moça da recepção pegue um post-it e escreva: o nome do cara que reservou e o período da reserva. Após fazer isso, ela vai no quadradinho que representa o quarto que o fulano escolheu e cola o post-it.
Como ela faria pra dizer quais quartos estão disponíveis? Contaria todos os quadradinhos que não houvessem post-it’s colados. Agora, tirando o meu da reta, como traduzir isso pro sistema? aheuheauauhe
Uma pergunta: o quarto terá uma reserva ou uma reserva terá um quarto?
Imaginemos como isso seria feito manualmente: um quadro na parede com vários quadradinhos, cada um representando um quarto existente no hotel. Em cada quadradinho, haveria 3 informações básicas: o número do quarto, o tipo (simplesinho, fodão, mais ou menos) e o preço da diária.
|||||||
|||||||
|||||||
Beleza, agora imagine que quando alguém vai lá e pede pra reservar o quarto, a moça da recepção pegue um post-it e escreva: o nome do cara que reservou e o período da reserva. Após fazer isso, ela vai no quadradinho que representa o quarto que o fulano escolheu e cola o post-it.
Como ela faria pra dizer quais quartos estão disponíveis? Contaria todos os quadradinhos que não houvessem post-it’s colados. Agora, tirando o meu da reta, como traduzir isso pro sistema? aheuheauauhe
Uma pergunta: o quarto terá uma reserva ou uma reserva terá um quarto?
[/quote]
Gostei…primeiro o negócio (o sistema) depois a tecnologia. Seria ótimo se alguem soubesse como a coisa toda funciona na realidade.
Respondendo: Na minha opinião, detesto ter que “achar” alguma coisa em sistemas mas vamos lá senão não tem brincadeira, a reserva é uma entidade constituida pela uma associação do quarto com “quem” é dono da reserva (fora outros detalhes). O quarto “X” tem uma reserva seria uma resposta “construida/deduzida” pelo modelo. Na verdade os quadradinhos (idéia bacana essa) seriam as reservas ao meu ver.