Despite the fact that age is inaccessible by the child class, if we have an instance of a Lion object, there is still an age value that exists within the instance. The age value just cannot be directly referenced by the child class nor any instance of the class. In this manner, the Lion object is actually “bigger” than the Animal object in the sense that it includes all the properties of the Animal object (although not all of those properties may be directly accessible) along with its own set of Lion attributes.
A concrete class must implement all inherited abstract methods, so option B is correct. Option C is incorrect; a superclass may have already implemented an inherited interface, so the concrete subclass would not need to implement the method.
1: Interfaces are always abstract.
Campbell Ritchie wrote: A class is an abstract datatype, but ... The word was not used in the same context in ”abstract datatype”. Although the answer No 1 was correct, that quote didn't help to explain it.
Campbell Ritchie wrote:'Fraid not. The phrase “abstract datatype” does not mean the same as “abstract class”. A class is an abstract datatype, but can usually be instantiated directly. You have found the wrong section.
Charles O'Leary wrote:. . . Bingo! (same book)
If you want the definitive answer, you need to go to the Java® Language Specification (=JLS). Fortunately you don't have to go far to find the answer. Last sentence in the first paragraph, and further on in §220.127.116.11. That also tells you about the keyword abstract.
Cozwaldo cozwald wrote:Thanks for the response , so just to clarify - Interfaces are always abstract , however an Interface may contain a static or default method (This method is not abstract - but as a whole the Interface is?)
I feel option 1 is incorrect.
To which i then added the abstract keyword to the interface, which did not give any compile time errors. (Which shows that interfaces are abstract - yet at the same time the only method on the interface has an impl?)
Katherine Reut wrote:
a) I "x"ed out the arrow pointing from a1 to "Alpha Object #1".
*This makes the arrow from "a1.b1" to "Beta Object #1" and the arrow from "a1.b2" to "Beta Object #1" be x'ed out too!
It should be clear that there is still a reference to the object referred to by a2, and that there is still a reference to the object referred to by a2.b2. What might be less clear is that you can still access the other Beta object through the static variable a2.b1—because it’s static.
Now imagine a test class has a method with a declared argument type of GameShape, which means it can take any kind of GameShape.
The key point is that the doShapes() method is declared with a GameShape argument but can be passed any subtype (in this example, a subclass) of GameShape.
Of course, the cool thing here is that any class from any inheritance tree can also implement Animatable, so that means if you have a method with an argument declared as type Animatable, you can pass in PlayerPiece objects, SpinningLogo objects, and anything else that’s an instance of a class that implements Animatable
As a bit of background, we’d like to clarify how we’re going to use the terms “argument” and “parameter” throughout this book:
arguments The things you specify between the parentheses when you’re invoking a method:
parameters The things in the method’s signature that indicate what the method must receive when it’s invoked: