| Autor |
Mensagem |
|
|
|
O formato da prova é da segunda maneira q vc descreveu.A própria kathy mensiona isso no livro.
|
 |
|
|
mfiuzajunior wrote:Isso eu entendi. é como se o membro protected, momentaneamente, ficasse private caso a classe C tentasse acessá-lo. Mas o fato é: efetivamente o membro continua sendo protected, visto que se a classe C quisesse acessá-lo, teria que extender o classe B, correto? pois mesmo extendendo a classe B, a classe C não teria acesso se o membro protected se tornasse private. Dessa forma, essa "transformação" é temporária, para impedir que outra classe, qua não pertença à hierarquia, tenha acesso ao membro.
Pois então mfiuzajunior, é como eu disse: Se a classe C extendesse B, ela iria enxergar o método. Quer dizer q ele SE COMPORTA como private, ele não se torna um, pois a regra é q um método protected só pode ser acessado fora do pacote da classe, através de HERANÇA.
Enfim, ele não vai deixar de ser um protected, apenas por se comportar assim.
|
|
|
|
O livro diz q a classe se comporta como private caso vc tente acessá-la através um classe fora do pacote q não seja subclasse de alguma das duas.
Mais ou menos assim, se A tem um método protected e uma classe B (fora do pacote) extends A, então esse método protected vai ser enxergado pela classe B.
Agora, se vc tem uma classe C fora do pacote q não extend nem A nem B, e tente acessar este método protected em B, vc não terá acesso ao método (como se ele tivesse se tornado private de B), exceto se vc extender uma dessas classes.
|
|
|
|
Ao instanciar objeto "d" (Derived) seu construtor chama primeiro o construtor da superclasse Base, implicitamente (super()), que vai invocar o método "addValue()" que foi sobrescrito na subclasse, fazendo "value" valer 20, após isso é executado o construtor da subclasse Derived, q adiciona mais 20 ao "value", resultando em 40.
Portanto, o método "addValue()" foi sobrescrito e não sobrecarregado, pois se fosse sobrecarregado, como a referência de "b" foi feita para a superclasse Base, o método "addValue" da subclasse não seria exergado qd fosse invocado.
|
|
|
|
gustavobs wrote:é como ele disse ...
c1. chama a superclasse...
vai ser criado um objeto A apenas como "ponte" para x... e x de A vale 5.
O que eu entendi é q o leolimas está dizendo q o método getObject() da classe CovariantTest foi "overrided" pelo método getObject() da subclasse SubCovariantTest, já q esse método retorna um tipo "co-variant" ao da superclasse (B extends A)...Então qd chamasse c1.getObject(), ele iria chamar o método da clase SubCovariantTest que sobrescreveu o da classe CovariantTest, logo, retornando B.
Acho q foi isso q ele quis dizer.
|
|
|
|
aaah, o gustavobs já disse  ....
|
|
|
|
O TestKiller q está aí é de 2004 mesmo, ou é só a data lá q ta assim?!
|
|
|
|
|
|