I'd been asking questions 'round here about the best way to deal with the lack of a Stack interface when working in Java, and got some good guidance.
That had me reading about LinkedList, Deque and Stack and caused me to forget what I'd learned precisely for just 815/816/819 preparation and what went beyond it, but anyway...
Well this is in the OCPJP forum because it concerns the explanation of an answer from the Sybex 816 book by Jeanne and Scott.
The sample program involved is:
I am fine and good with that so far...the question probably wants to test if we know that offer() and add() add to the tail of the list and .pop() and .peek() grab from the head when using a LinkedList as a LinkedList per se, via. a LinkedList reference. I made a yucky face because we are mixing .offer() or .add() rather than .push() and the mixed metaphor offended me, but not the compiler.
Actually, since they go ahead and say the question means to be implementing a Queue, I do think I object to the use of offer(), rather than offerLast() which doesn't cost any more and is more self-documenting to me, since we are just dealing with a linked list. But, if the question means to be about a Queue usage of LinkedList, not a Deque, you say, so we should just use .offer() there, which is a synonym for .offerLast() in Deque, but the only way to fly when making use of the Queue interface.
So I'd argue that this is really a question about a Deque being used FIFO-style....
Holy mixed-metaphors, Batman!!
I've dealt with code similar to this thru-out my whole career, tho I tried not to write it, but I wonder if this question was intentionally made confusing to prepare us for the Sadists in Oracle's Certification Exam group or by accident?
My actual question is in the explanation:
This is a FIFO (first-in, first-out) queue. On line 7, we remove the first element added, which is "hello". On line 8, we look at the new first element ("hi") but don’t remove it. On lines 9 and 10, we remove each element in turn until no elements are left, printing hi and ola together. Note that we don’t use an Iterator to loop through the LinkedList to avoid concurrent modification issues. The order in which the elements are stored internally is not part of the API contract.
So my original complaint was that I didn't see why we couldn't use a ListIterator to loop thru the LinkedList, it seemed ideal for that purpose if the code is single-threaded, and avoids the goofy problems you get if you try to remove elements using enhanced for loops.
I am not sure what is meant by "The order in which the elements are stored internally is not part of the API contract." I find that very confusing, because I thought it is.
I understand that Queue may be different, but we don't have a Queue reference, thanks to LVTI we have a LinkedList<String>.
I still love Java and the book, and Deques and LinkedLists, but only after getting the question right and looking at the answer do I realize why I was filled with such anxiety upon hitting it.
We use LVTI so our Dog is just a Dog, and the methods being called via. the various Interfaces implemented by our Dog--errr, LinkedList make it hard to tell what the usage is intended to be until we see the answer. Since we have a LinkedList, it feels like we could also have successfully used a ListIterator to produce the output if we felt like it -- I don't see the missing API contract involved.
snakes are really good at eating slugs. And you wouldn't think it, but so are tiny ads: