Campbell Ritchie wrote:If you submit something with a public field for a coding interview, you will fall at the first hurdle If that sort of code is typical of that book, it isn't worth reading, I am afraid.
Junilu Lacar wrote:Let's ignore the flaws of this design for a minute and just analyze it at face value.
The class has three fields: next, prev, and last. The next field is the node that succeeds the current node (comes after "this" node) and the prev field is the node that precedes the current node (comes before "this" node). The last field references the node that is the tail of the linked list, that is, it's the last node in the linked list that the current node (this node) is part of.
Notice how "this node" refers to the current node which means it's whatever particular node instance we're calling methods on. So, the expression if (this == last) literally is saying "if this node object is the same object that the last field refers to" -- in other words, it's saying "if this is the tail of the linked list".
The if-statement on lines 20-22 updates the last field to the node n if the current node is the last node of the linked list. This is why. If the current node is the last node in the linked list, then this == last will be true. Given a new node, n, that will then come after the current node (this node) in the linked list, then the current node will no longer be the last node in the linked list, it will be the node that comes before the new last node, n. That is, when we set node n to be the node that comes after the current node ("this" node), then node n will effectively become the last node in the linked list. Therefore, we need to assign n to the last field to reflect that new status.
Hopefully, that clears the matter of this == last for you. You should note, as already mentioned, that this is a very poor object-oriented design since the "knowledge" of what are the head and tail nodes of a linked list should not be managed this way but in a LinkedList class instead. The Node class would ideally be a nested class of LinkedList and probably shouldn't even be accessible outside of the LinkedList class.
But this is the design you have to study and work with so you'll have to make the best of a poor design.
Campbell Ritchie wrote:The node shouldn't be a top‑level class. It has no existence on its own, merely constituting part of a larger structure.
Did you copy that code from somewhere else or write it yourself? If somewhere else, please tell us
Campbell Ritchie wrote:Please supply the author's name.
Md Zuanyeed Kamal wrote:. . . page no 93 of 6th edition of this her book, . . .
Please practise drawing the structure of a linked list, and practise writing its simple operations. Make sure to give it a private nested Node class and to maintain references to the head Node. Start with a singly‑linked list and then enhance it to a doubly‑linked list, which has a tail Node as well as a head. Then you will understand what the quote from the book means.
Please use the quote button, not green text; some people can only read certain colours.
Junilu Lacar wrote:I believe we've seen this design before. If this Node class was encapsulated in a LinkedList class, then managing the head of the list this way wouldn't be too bad. However, if this were a top-level class where client code had to keep a reference to the head of a list, then it's not a very good design, in my opinion. I would even guess that it's something that some instructor took from a non-object oriented language and tried to directly translate it to Java. If that was the case, then the instructor was being lazy at best.
Campbell Ritchie wrote:Why would a delete method return a Node in the first place? Shouldn't it be called remove() to match the remove() method in java.util.List? Wouldn't it return the value removed, so its return type would be int? Does that description say anything about the potential inefficiency of iterating a linked list?
Deleting a node from a linked list is fairly straightforward. Given a node n, we find the previous node prev and set prev. next equal to n. next. If the list is doubly linked, we must also update n. next to set n. next. prev equal to n. prev. The important things to remember are (1) to check for the null pointer and (2) to update the head or tail pointer as necessary.
Carey Brown wrote:
Piet Souris wrote:As Paul explained, in line 2 you set your String ultimate to null. Next you use that same null array in line 7, and that gives you this NPE. Save is to set the String to an initial size of list1.size(), like in:
Does the method 'compareMapping' return a String?
Piet Souris wrote:Beware that the two maps may differ in the keys.
And to add to Knute's forEach: you can do the exercise in one line, using the Map.merge() method.
Paul Clapham wrote:Well, yeah. Look at line 2. And then of course you're going to get a NPE at line 7.
Piet Souris wrote:
If you get your code up and running, can you explain the idea behind the subtraction of the values?
Piet Souris wrote:I gave you a solution, just read my reply. Note that a Collection does not have a get method, so you must use two iterators.