É errado uma classe da camada Model ter uma coleção objetos de uma classe da camada Control?
Não é recomendável. Explique melhor sua situação para que possamos sugerir uma alternativa.
Abraços
Com certeza, é errado. Model não pode conhecer o Controller, nem a View. E outra, Model, View e Controller não são camadas. Não tem essa de “camada” Model, não!
Seria até interessante mostrar o seu exemplo, pro pessoal discutir melhor.
Eu estou montando uma simulação de jogo de futebol. Ai presumi que o campo vai na Model, assim como a bola. Como o jogador exerce controle sobre a bola, penso que ele iria para a parte de Controle. Mas como dizer ao campo o número de jogadores? O campo está ali só pra guardar essas informações, e outras como número de gols, etc.
Provavelmente está errado, mas é que sou iniciante em Orientação a Objetos.
Creio que não. O jogador, assim como o campo, é uma entidade do jogo e deve ficar no modelo. O controle é composto por classes que efetuam a conversação entre a visão e o modelo. Você levou ao pé da letra demais ao interpretar o controle que o jogador exerce sobre a bola como sendo o controle do MVC.
Certo, essa parte eu entendi. Mas com isso surgiu outra dúvida. Vamos dizer que eu quero fazer o jogador chutar e exibir isso na tela. Quem chuta a bola é o jogador, que é um objeto da classe Model. Não ocorreria uma relação da classe View com a classe Model nesse caso(até onde sei é errado)?
Quando alguma entidade do modelo sofre uma ação, suas propriedades mudam e essa mudança é refletida na visão. Dessa forma, você deve enumerar primeiro as conseqüências da ação. No seu caso, como você está modelando a classe Bola? O que acontece com os valores dos seus atributos quando um jogador a chuta?
Vamos fazer uma análise bem simplória e supor que seu jogo de futebol é visto de cima. Nesse contexto, a classe Bola tem dois atributos: X e Y, coordenadas que indicam a posição da bola em determinado momento. Quando um jogador a chuta, os valores de X e Y mudarão, e a visão deverá refletir essa mudança. Como? Depende. Se você estiver fazendo uma aplicação Swing, você pode usar o padrão Observer para que mudanças no modelo reflitam automaticamente na visão. Se estiver fazendo uma aplicação web, você pode delegar a responsabiliade de atualização da visão para o controle.
Mostre mais detalhes de sua aplicação pra gente dar uma olhada.
Quando alguma entidade do modelo sofre uma ação, suas propriedades mudam e essa mudança é refletida na visão. Dessa forma, você deve enumerar primeiro as conseqüências da ação. No seu caso, como você está modelando a classe Bola? O que acontece com os valores dos seus atributos quando um jogador a chuta?
Vamos fazer uma análise bem simplória e supor que seu jogo de futebol é visto de cima. Nesse contexto, a classe Bola tem dois atributos: X e Y, coordenadas que indicam a posição da bola em determinado momento. Quando um jogador a chuta, os valores de X e Y mudarão, e a visão deverá refletir essa mudança. Como? Depende. Se você estiver fazendo uma aplicação Swing, você pode usar o padrão Observer para que mudanças no modelo reflitam automaticamente na visão. Se estiver fazendo uma aplicação web, você pode delegar a responsabiliade de atualização da visão para o controle.
Mostre mais detalhes de sua aplicação pra gente dar uma olhada.[/quote]
Vou fazer utilizando Swing. Seria assim mesmo, olhando de cima, igual Football Manager(figura abaixo):
http://www.itreviews.co.uk/graphics/normal/games/g203.jpg
Estou pensando em como vão ficar as classes, ainda não comecei a implementar. Realmente faz sentido usar o padrão Observer, só que ai eu não teria um controle, só modelo e visão, já que jogador e bola são do modelo e iriam alterar algo na visão. Ou eu não estou conseguindo ver algo?
Você só não precisaria do controle caso nenhum usuário interagisse com a interface. Se houver alguém que provoque modificações na visão - pressionamento de botão, digitação de textos em caixas de texto - você ainda precisará do controle para propagar as alterações da visão para o modelo. A vantagem de usar Observer é que o caminho inverso é feito automaticamente, sem a ajuda do controle.
Então, não estou conseguindo visualizar as classes de controle. Digamos que haja uma situação de disputa de penaltis e o usuário pode escolher se quer bater na esquerda, no meio ou na direita. Se a classe Jogador possui o método chutarBola e ela está no modelo, onde entra o controle nesse caso?
Nessa situação, deve haver uma classe que herde de JFrame e possua componentes de interface para que o usuário possa indicar o canto do penalty - essa classe pertence à visão. Deve haver também classes que guardem o estado da aplicação e que modelem a trave, o jogador, o goleiro, a bola… Essas pertencem ao modelo. O que está faltando aí? Falta uma classe que extraia da visão a escolha do jogador e propague essa escolha para o modelo, chamando os métodos necessários para tal. Essa classe é o controle.
Então, no caso de uma aplicação Swing você tem duas opções:
- efetuar as mudanças no modelo diretamente no ActionListener. É mais simples, mas tem a desvantagem de deixar o controle atrelado à visão, de forma que se um dia a sua visão mudar - se você resolver fazer o mesmo jogo usando JME, por exemplo - o controle terá que ser reescrito.
- criar classes de controle à parte que serão chamadas pelo ActionListener. É mais complicado, mas fica mais fãcil mudar a visão caso haja a possibilidade.
Como otimizar prematuramente não é bom, e sabemos que sua aplicação será só Swing, utilize a primeira opção.