Tomas dos Santos Rodrigues E Silva

Hugo Carvalho De Almeida Navarro

Acho que você comentou o print e esqueceu de descomentar. Descomentei e foi legal, mas tirei um pouco de ponto. A variável estática que era pra testar não era a da pergunta, também. Faltou a segunda pergunta da 2, e a terceira pergunta está confusa (você fez os testes?)

O código não compilava porque esqueceu de mandar o Carona, peguei seu código do lab anterior e modifiquei pra funcionar e não dar 0 (mas só dessa vez). Não ficou claro se você entendeu a 3)b). Muda de acordo com a atribuição, verdade, mas como ficou? Gostei da formatação da saída.

Me ajuda muito compilar se você me mandar na estrutura de pacote, caso use pacote (no caso, deixar os códigos dentro de lab4/ por exemplo).

Não é pra ter chamado a superclasse nos objetos, e sim GrupoPublico. Você até colocou o print certo, e deu a resposta certa, então talvez tenha só escrito errado.

Quando é static, é pra continuar chamando Grupo na variável a.

A resposta da 3)b) ficou confusa. A diferença é que como o método não é mais estático, ele vai chamar o atributo da instância do GrupoPublico (mesmo sendo da classe Grupo)

Gostei da formatação do print, do código, e das respostas completas.

Na 3)a), deu a mesma coisa provavelmente porque você não criou o método getStatic como Static. É pra continuar mostrando o atributo da classe.

Deu warning, e foi um warning mais problemático. Não esqueça de colocar a classe quando criar um ArrayList. Respostas completas

Só não testou as variáveis estáticas (fora as da pergunta), mas gostei das respostas.

Não dá pra ter muita ideia do que é o que na saída, aparecendo null, false e uns números. Na 3)b), era pra retornar o valor da instância. Tentei entender o que você pode ter feito errado, mas como tá tudo comentado não consegui. Pode deixar o código referente as respostas, nas próximas vezes, se não prejudicar o lab (se não der erro de compilação e tal).

Não ficou claro como a herança possibilita encapsulamento. Encapsulamente ocorre independente da herança, e não consigo pensar em muitas maneiras onde a herança auxilia isso. É mais na reutilização de código, mesmo.

Deu um warning por um import errado (import sun.misc.Perf;). Não chamou a variável estática diferetamente mas testou o gerador de id. Boas respostas

Na 2), na verdade o final na classe só indica que ela não pode ter subclasse. Na 3)a), era pra a continuar chamado Grupo. O problema foi só que você deixou o método getStatic sem ser static (aí sim, ele vai acessar a variável referente a instância)

Os prints estão um tanto desorganizados. Tem uns null no meio, é confuso entender. Também tente deixar o código padronizado no número de espaços entre if e etc.

Eu sei que parece esperto não colocar chaves quando você só tem uma linha em baixo de um bloco, mas na prática não é recomendado: tem n formas de alguém, ou você mesmo, se confundir na pressa. Não tirei nem vou tirar pontos disso, se quiser continuar assim. Achei legal que tentou deixar uns 100 caracteres por linha nas respostas, fica mais fácil de ler (deixar o código todo assim é melhor ainda :).

Por algum motivo os prints dos testes de variáveis static estavam comentados. A resposta das duas primeiras foram boas, mas na terceira foi confuso. Na a) era pra ter chamado os 3 membros, não ficou claro o resultado de cada um. Na b) também não ficou.

Dá um exception no método main, na tentativa de responder a pergunta. No caso da 3, quando não entender alguma coisa pode mandar email, perguntar no lab, ir no atendimento.

Falar que o principal benefício é a economia de linhas não é bem verdade. Economizar linha nem é necessariamente um benefício. Acho que você pensou em algo como reutilização de código, o que é um tanto diferente. O problema de você ter 10 métodos que fazem a mesma coisa não é bem que você tem 10x mais código, e sim que se você precisar mudar em um dos lugares, vai precisar mudar em todos, além de ser difícil achar esses 10 lugares e se você esquecer em um deles pode ser difícil encontrar o erro. É bom sempre centralizar os comportamentos, quando possível. Fora isso, ficou bom

Gostei bastante de todas as explicações e tal. Uma coisa: não faz sentido você sobrecarregar o toString por dois motivos: 1 - sobrecarga é bom usar quando é um método muito parecido que pode receber argumentos diferentes. No caso é um método parecido, mas faz muito mais sentido você mudar o nome para ser mais descritivo do novo comportamento (exemplo toStringSemRecursao), mas jamais coloquei um argumento a mais na função só pra sobrescrever. 2 - Esse método toString sobrecarregado não vai ser chamado pelo print. A classe object tem só o toString() sem argumento, logo esse não vai sobrescrever nenhum método e só serve pra você mesmo. Mais razão pra usar um nome diferente.

A gente vai deixar explícito no próximo lab pra não pedir mais nada pela entrada, não se esqueça de mudar, daí. Na resposta 3)a) ficou "estranho" falar que todos ficaram com o valor de "c" se a variável é static, já que o valor é o mesmo pra toda instância. Melhor falar que ficou com o valor de GrupoPublico/

Verificar o uso das variáveis estáticas era algo separado da pergunta final.