Professional Documents
Culture Documents
Adriana Matsubara
Não entregou.
1
Erick Massa Sprengel
Não entregou.
Fábio Verrone
Atrasado 1 dia (-0,5)
• Seria interessante se sua implementação perguntasse qual Jogador se deseja usar
(Humano X Humano, Computador X Humano, etc).
Carta
• A classe deveria ser “friendly” para não ser acessada por classes de outros pacotes
(-0,25)
o A ideia do pacote não é uma parte da solução, mas por si só não resolve o
problema...
Baralho
• Ao invés de fazer “new Carta(ICarta.QUATRO + j,ICarta.OUROS + i);” você poderia
usar os índices do vetor para construir o baralho, fazendo “new
Carta(ICarta.VALORES[j], ICarta.NAIPES[i]);
• Como o i e o j tem um significado no domínio (no caso, naipe e valor), prefira usar
nomes que representam esse significado ao invés de nomes de meras variáveis
controladoras de “for” (-0,1)
IJogadorAutomaticoManilhaVariavel e IJogadorAutomaticoManilhaFixa
• Você não deveria ter alterado o nome das interfaces... (-0,25)
o Alterar o pacote delas era uma necessidade, já que o Java não consegue
referenciar classes sem pacote, mas alterar o nome delas você está
fazendo uma alteração mais complicada...
JogadorGeral
• Essa classe deveria implementar IJogador. (-0,5)
o Não entendi o porquê dos jogadores controlados por um ser humano não
serem IJogadores... Ao fazer isso, você perde toda a facilidade que a
interface oferece de ter múltiplas implementações!
o A ideia desta aula era exatamente trabalhar com o polimorfismo ao ter
mais uma implementação de IJogador.
o Apesar desse problema sério, a ideia de criar uma implementação “geral”
foi muito boa.
Rodada
• O código deveria trabalhar com IJogadores e não com JogadoresGerais (problema
do JogadorGeral).
• Ao invés de fazer os “instaceof” na Rodada, o melhor seria criar duas classes filhas
que definem o comportamento quando o jogo é manilha fixa e quando é manilha
variável (Aula5) (-0,25)
• Estranho a comparação ficar na classe Jogador, até porque as classes Jogador não
usam-a.
o Se o motivo for deixar em apenas 1 lugar esse método, ok. Mas por
questões de elegância, me parece que a melhor solução é colocar um
método abstrato “comparar” na Rodada e as classes filhas dela aí sim
chamarem os métodos em Jogador.
Mas perceba que esse motivo só faz sentido se as classes jogador
usarem esse método... O que não é o caso!
JogadorHumanoManilhaFixa e JogadorHumanoManilhaVariavel
• No método “jogar”, ao invés de fazer uma sequência de ifs para a escolha, faça
“else if” (-0,1)
2
Felipe Regis e Silva
Não entregou.
3
• Talvez o nome “getUltimaCarta” seja mais apropriado que o nome “getCarta”.
• Talvez o nome “recebeCarta” (ou algo similar) seja mais apropriado que o nome
“setCarta”. O problema é que não se está dando um “set” na carta, mas jogando
uma carta à mesa.
Jogo
• Os métodos (a menos do construtor e do jogarMão) deveriam ser protegidos. (-
0,1)
• O jogo poderia receber somente dois jogadores (ao invés de um vetor), já que seu
jogo trabalha só com 2 jogadores (por causa da mesa)...
• O método jogarMao não precisaria ser abstrato. No JogoManilhaVariavel, o
“distribuirCartas” poderia também definir o vira (já que é na distribuição de cartas
que o vira é definido em um jogo normal).
Lucas H. G. B. Estevam
• Mesmo código do Felipe Zequeto Bozoni (converse comigo)
o Nota / 2
Aula 5 (Atrasado 1 semana: -1,0)
JogadorSimples
• Por questões de elegância, ele deveria implementar IJogador – por mais que isso
não faça muita diferença prática.
JogadorManilhaVariavel
• O método “getVira” não parece necessário.
JogoManilhaVariavel
• O getVira e o setVira são desnecessários (-0,1)
Jogo
• Atribua os valores às variáveis “carta1” e “carta2” na sua declaração (na rodada) (-
0,1)
Aula 6
• O nome do pacote “Baralho” está fora da convenção do Java (-0,1)
JogadorHumano
• Não acho uma solução muito elegante ele implementar as duas formas de
IJogador (manilha fixa e variável), mas tudo bem.
• Mas pelo menos evite copy-paste. Faça o método receber do manilha variável
chamar o método receber do manilha fixa, já que eles são iguais - só tem o detalhe
do vira (-0,1)
• O atributo vira deveria ser privado (-0,1)
• Defina o Scanner como um atributo.
4
Márcio Rene Ikeda
Atrasado 1 dia: -0,5
Carta
• Faça os vetores “valorStringList” e “naipeStringList” como constantes (final e
static) e use a convenção de nomes do Java para isso (-0,1)
Baralho
• O vetor de cartas criado no construtor do Baralho deveria ser do tipo
“ICarta[]”(Aula4) (-0,1)
JogadorHumanoManilhaVariavel
• Não é muito elegante que essa classe herde de JogadorHumanoManilhaFixa. Ao
fazer isso, um objeto dessa classe pode se passar por um objeto de
JogadorHumanoManilhaFixa. Para esse projeto não é um problema, mas é
estranho.
CriadorJogador
• Sugiro que essa classe seja abstrata (e final) – já que não faz sentido existirem
objetos dela. Com isso, os métodos podem ser todos static.
InteracaoJogo
• Evite nomes como REGRAMANFIXA e, principalmente, REGRAMANVAR. Use a
convenção do Java e evite siglas estranhas. Faça REGRA_MANILHA_FIXA e
REGRA_MANILHA_VARIAVEL. (-0,1)
• O conteúdo dessa classe poderia ficar na classe Main... Mas tudo bem.
JogoManilhaVariavel
• Faça o atributo vira privado (ou protegido) (-0,1)
5
Maria Carolina Falini Galvão
Não entregou.
6
Jogador
• Você deveria ter criado um novo tipo de Jogador – e não colocado um método
“jogComputador” no Jogador. (-0,75)
o A interface IJogador define um jogador de truco. Ela pode ter várias
implementações. Uma delas é um jogador simples controlado por
computador. Outra é um jogador controlado por um usuário!
o Na prática era só criar uma classe filha dessa que redefine os métodos
apropriados (e para suas filhas também)!
Jogo
• Faça o main criar os jogadores apropriados (perguntando qual jogo e se o usuário
quer jogar) e passar para o Jogo os objetos Jogador criados.
• Os atributos da classe Jogo deveriam ser protegidos (ou privados) (-0,1)
• Os método “jogaHumano” e “jogaComputador” só são necessários porque você
não criou uma nova implementação de IJogador. Se você tivesse feito isso, seu
código seria independente desses detalhes.
• As ICartas c1 e c2 não são atributos. Elas são variáveis da rodada que você passa
para dois métodos (-0,1)
o Em compensação, os IJogadores deveriam ser atributos, assim como a
pontuação!
• Porque o Jogo tem um “vira” se só o jogo de manilha variável precisa dele? Essa
informação só deve aparecer na classe JogoVariável! (-0,1)
• O método inicia deveria ser definido aqui como abstrato, já que as duas filhas o
possuem (-0,1)
• A classe Jogo deveria ser abstrata. Não faz sentido criar uma instância de Jogo (-
0,25)
• Ainda não precisava ter pontuação, mas tudo bem.
Regra
• Incorpore a classe Regra na classe Jogo. Defina o método “definePoder” como
abstrato e coloque a implementação dele nas classes JogoFixa e JogoVariável. (-
0,25)
o Perceba que a regra depende do Jogo!
7
• Não faça os atributos static! Ao fazer isso, todos os objetos do tipo JogadorSimples
compartilham essa informação... Ou seja, todos tem o mesmo nome, as mesmas
cartas e a última carta! (-0,5)
• Não defina o método “receberCartas” de 1 parâmetro como abstrato. Ao fazer
isso, você obriga que o JogadorManilhaVariavel tenha esse método também! (-
0,25)
JogadorManilhaFixa
• Essa classe não deveria ser abstrata! Ao fazê-la abstrata, você impede que existam
objetos desse tipo! (-0,25)
JogadorManilhaVariavel
• Essa classe deveria herdar de JogadorSimples. Sem a herança, ela não tem os
métodos do JogadorSimples! (-0,25)
Truco
• O main deve criar apenas os objetos necessários e pedir para eles fazerem o
serviço requerido. Tudo o que fizer parte do jogo (dar as cartas, pedir para eles
jogarem etc) deve ficar em uma classe (-0,25)
• Nome da variável “J1” e “J2” fora da convenção do Java (-0,1)
• Não faça “if(jogo == "Manilha fixa") {“. Compare Strings usando o método
“equals”. (-0,1)
o No seu caso seria mais simples perguntar se o jogador quer jogar jogo de
manilha fixa ou variável e pedir para ele responder com números (ex: 1 se
for manilha fixa ou 2 se for variável).
• Faça o método “compararCartas” retornar um inteiro – assim evita ter que
comparar de novo se forem cartas iguais (-0,1)
• Código não compila (-0,75)
o Faltou um “}”.
o Não é possível fazer “IJogador J1 = new IJogador("Jogador1");”! Não é
possível criar objetos a partir de uma interface – já que ela não tem
implementação.
Você pode declarar a variável simplesmente como “IJogador j1;”
o Problemas de classes abstratas e métodos incorretamente definidos!