Charles O'Leary

Ranch Hand
+ Follow
since Jul 10, 2014
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
28
Received in last 30 days
1
Total given
10
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Charles O'Leary

Jeanne,

B. A concrete subclass must implement all inherited abstract methods.

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.



I guess I'm trying to say that B can potentially be "interpreted" as being ruled out by some readers because the word first is (purposefully?) missing?  Indeed, Square is a (non-first) concrete subclass that must not implement all inherited abstract methods?  Square is a larger object than it's predecessors, and there really are three inherited abstract methods in Square's entire family tree?  Another alternate, "B. A concrete subclass must implement all inherited abstract methods of its direct/immediate parent class"?

Can't wait to hear your thoughts!

Thanks,
Charles
Hi Jeanne!

If Square extends the concrete class ChildRectangle, which extends Rectangle thus it (ChildRectangle) implements name(). Here, Square would not need to implement perimeter(), area(), nor name() because of Square's ChildRectangle and Rectangle parents.   So none of the aforementioned methods would be abstract from Square's point of view.  B would not be correct in this context?  

Do you see the point I'm trying to make?  The book's "final" answer reminds me of why (in in the book) you mentioned in practice, that you don't necessarily want to mark classes (or answers in this case?) as "final" (paraphrasing) ... you don't know all the permutations that may need to later come.

Thanks,
Charles
Q: Which of the following is true about a concrete subclass? (Choose all that apply)
A. A concrete subclass can be declared as abstract.
B. A concrete subclass must implement all inherited abstract methods.
C. A concrete subclass must implement all methods defined in an inherited interface.
D. A concrete subclass cannot be marked as final.
E. Abstract methods cannot be overridden by a concrete subclass.


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.




Why does C's (incorrect answer) provided explanation somehow not apply to B?  Asked differently, how is B correct while C is not?  Seemingly to me, both B and C potentially suffer from C's explanation?  (Although not a choice, the answer should be none of the above?)
Campbell,  

possible answer provided per the question:

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.



My quote did not have any buts, exceptions, most of the times, and/or usuallys, so the word "always" was implied and was seemingly, I thought, exactly like your eloquent and concise §9.1.1.1.  The text (my quote) wriiten another way:  An interface is (always) an abstract datatype. (Period ... no buts) It defines a ...blah, blah, blah.  

So, not to beat a dead horse, but please help me to get my understanding correct on this.  I'd love to correct any misunderstanding that I may have regarding the quote that I provided.  

Campbell Ritchie wrote:

Charles O'Leary wrote:. . . Bingo! (same book)

'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.
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 §9.1.1.1. That also tells you about the keyword abstract.


Campbell,
I did a "find" just to be sure.  But, please note that the word "class" was only used by you.  I think "abstract" was used in the correct context, especially as you outlined so eloquently in pointing out  §9.1.1.1.
I've enjoyed telling you that you were right all along!

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


Bingo! (same book)
... And welcome to the ranch Cozwaldo.  (I think you have this one figured out.)

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



It appears that you have answered your own question?

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!



Hi Ranchers,

Could you kindly refresh my memory on the specific rules for the above asterisk?  Or, perhaps, provide more insight?  By the way, I think this is one of the better diagrams that I've seen since it "keeps" both sets of b1&b2 within heap objects referenced by a1 and a2.  If you have a better diagram, by all means, please feel free to share it.

Answer:


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.



My memory somehow wants to see a1, a1.b1, and a1.b2 as three separate (independent) references, similar to how the above answer seemingly (to me) treats a2, a2.b1, and a2.b2 as separate references?

Thanks in advance!
Welcome. Congratulations on your latest book Hanumant!
page 96 & 104, "argument" should be "parameter"
96:

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.


104:

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




reference page 49 of OCA Java SE 8 Programmer I Exam Guide (Exams 1Z0-808)

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: