AULA 6 – 15/03/2010

Adriana Matsubara
Não entregou.

Adriano Rogério Santana de Oliveira

Aula 4 (Atrasado 2 semanas: -2,0)
BaralhoTruco
• O método “embaralhar” deveria zerar o topo (senão uma carta, aleatoriamente é
desprezada quando ele é chamado depois do baralho já ter sido usado) (-0,1).
Regras
• No método “eManilha”, o “for” deveria ser até “manilhas.length” (e não até 3). (-
0,1)
o Use valores calculados ao invés de constantes. Fica mais fácil alguém
entender o seu código
• Também acho que o vetor manilhas deve ser uma constante, mas da forma que
está é estranho que o construtor da classe o crie. A forma mais elegante de criá-lo
(e assim deixá-lo final também) é fazer:
private final static ICarta[] MANILHAS = { new Carta(ICarta.SETE,
ICarta.OUROS), new Carta(ICarta.AS, ICarta.ESPADAS), ...};
JogoSimplificado
• 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 (pode ser na JogoSimplificado mesmo, mas
separe o main) (-0,25)

Alexandre Massao Miyogi Arakoshi

Não entregou.

Bruno Bandeira de Azevedo

Não entregou.

Bruno Medeiros de Barros

Não entregou.

Daniel Matsusita Nakasato

Não entregou.

Daniel Texeira da Silva

Não entregou.

Enlai Lima Cheng

Não entregou.

Eric Kendi Shiraishi

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.

Felipe Zequeto Bozoni

• Mesmo código do Lucas Estevam (converse comigo)
o Nota / 2
Aula 5 (Atrasado 1 semana e 1 dia: -1,5)
Carta
• Cuidado: os vetores VALORES e NAIPES em String tem o mesmo nome dos
atributos definidos na interface que essa classe segue... Isso pode gerar uma
confusão na hora de chamar tais vetores.
o É por isso que na saída não aparece o nome do vetor certo... Estranho
você ter dito que no Eclipse funciona...
o O ideal é usar outro nome, como VALORES_EM_STRING ou algo do
gênero.
• Os vetores de String não são usados (-0,1)
o Eles permitem simplificar o método toString, mas para isso você precisa
usá-los!
JogadorManilhaVariavel
• Não parece ser útil o método “getVira”.
JogoDeTruco
• Atribua os valores às variáveis “carta1” e “carta2” na sua declaração (as cartas
jogadas) (-0,1)
• Em geral é melhor guardar o resultado da comparação em uma variável e evitar
que a comparação seja feita mais de uma vez... Não que seja um problema sério
neste caso
ManilhaFixa
• Defina as manilhas usando as constantes em ICarta (por exemplo, ICarta.QUATRO
ao invés de 0) (-0,1)
ManilhaVariável
• Não parece ser útil o método “getVira”.
Aula 6 (Atrasado 1 dia: -0,5)
• Nome do pacote “Baralho” está fora da convenção do Java (-0,1)
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...
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.

Fernando de Andrade Pereira

• Boa implementação!
Mesa

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).

Henrique de Souza Nobrega

Não entregou.

João Marcelo Pereira de Moraes

Não entregou.

Leonardo Oliveira Teixeira

Não entregou.

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.

Márcio Carlos Perin Tedesco

Não entregou.

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)

Marcos Inky Tae

• Veja uma forma de imprimir na saída o que está ocorrendo durante o Jogo. Não dá
para saber o que o outro jogador jogou, ou mesmo quem ganhou a rodada (e como). E
se o jogador é computador, não é legal ver as cartas dele (perde um pouco a graça).
Carta
• Uma forma elegante de gerar o “toString” é criar dois vetores: um com a
representação dos naipes em string e outro com a representação dos valores em
string. A ordem das cartas nesse vetor segue a codificação dos naipes e valores,
assim, por exemplo, a String na posição ICarta.QUATRO é “quatro”...
JogadorSimples
• Você não precisa chamar o nome da interface ICarta através de seu nome
completo já que há um “import” para essa classe (-0,1)
o O mesmo vale para todas as classes e interfaces do pacote jogadores.
o No TrucoMain você também não precisa usar os nomes completos já que
há o import.
JogadorHumanoManilhaFixa
• O atributo “cartasNaMao” deveria ser protegido ou privado. (-0,1)
• Não faça “if (cartasNaMao[i] == true)”. Faça simplesmente “if (cartasNaMao[i])”.
Como a variável é booleana, você não precisa compará-la com true ou false (-0,1)
• Ao invés do vetor cartasNaMao, você simplesmente poderia ter usado null para
“marcar” que a carta já foi jogada no vetor “cartas”.
• Tudo bem o copy-paste aqui... Se você conseguisse evitá-lo, ótimo. Mas como há
uma herança – e não dá para fazer herança múltipla, é difícil fugir.
o O estranho é você não ter conseguido fazer delegação. O problema da
delegação é que você teria que delegar todos os métodos do
JogadorHumanoManilhaVariável para o JogadorHumanoManilhaFixa...

5
Maria Carolina Falini Galvão
Não entregou.

Mauricio Takecita Uehara

• Use as interfaces da Aula5!!! (-0,5)
o Existem 3 interfaces e não apenas a interface Jogador!
Jogo
• Ao invés de definir o método “novaRodada” como abstrato, você poderia colocar o
código da novaRodada nele, tirando apenas a parte do construtor (-0,1)
o Perceba que o seguinte código é igual para as duas implementações de
Jogo:
System.out.println("\nRODADA 1");
rodada.darCartas();
rodada.jogadoresJogam();
placar.atualizar(rodada.vitorioso());
placar.mostrar();
Para resolver o problema da construção da rodada (que esta não é
comum), sugiro que ela seja feita no construtor do JogoManilhaFixa e
JogoManilhaVariável. Defina também um método “iniciar” que pede para
iniciar uma nova rodada. Defina também a rodada como um atributo do
Jogo. Isso permitirá reusar o código (perceba que no final das contas só o
construtor dos Jogos serão diferentes).
Rodada
• No método vitorioso, avise ao perdedor que ele perdeu.
• Como é o IJogadorManilhaFixa que tem o método receber com 1 parâmetro,
defina o método “darCartas” como abstrato na Rodada e coloque a
implementação na RodadaManilhaFixa
o Na verdade, ao usar as novas interfaces você teria esse problema... Use-
as!
JogadorControlado
• O atributo scanner deveria ser privado (ou mesmo protegido) (-0,1)
• O método “receberCartas” é quase igual ao da classe pai. Use o “super” para
aproveitar o código (-0,1)
o Se você fizer:
super.receberCartas();
/** Mostra ao usuario sua mao naquela rodada */
... // o resto do seu código
Funcionaria...

Oscar Zibordi de Paiva

Não entregou.

Rafael Elias Nascimento

Carta
• As variáveis “naipe2” e “numero2” não tem um nome apropriado... O que quer
dizer o “2”? Se eles são a representação em String, algo como “naipeStr” ou
“naipeEmString” seria mais adequado... (-0,1)
• E coloque um “ de ” entre o naipe e o valor em String – ou pelo menos um espaço!
• 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...

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!

Rodrigo Akira Kumazawa

Não entregou.

Tiago Schep Lopes

Não entregou.

Victor Meireles de Sá e Silva

Aula5 (1 semana atrasado: -1,0)
Carta
• Nome das constantes “x” e “y” são inapropriadas... Elas são valores e naipes em
string (-0,1)
• O atributo poder é desnecessário (-0,1)
Baralho
• O construtor do Baralho está errado. Faltou definir adequadamente os naipes. (-
0,1)
o Evite esse copy-paste. Faça um for que varre os naipes.
JogadorSimples

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!

Weder Castilho de Oliveria

Não entregou.

Yuri Robero Amaral Gaspar

Não entregou.