Two Parts are equal if and only if they have the same:
The method toString should print all of the part information on a single line in the order name, number, ncage, niin and each value should be labeled in the text output.
One possible example:
PART: Widget, purple, P/N: 12345, NCAGE: OU812, NIIN: 1234-12-123-1234
In PartTest, ensure that your tests for the equals method meets the following criteria:
It is reflexive: for any non-null reference value x, x.equals(x) should return true.
It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
For any non-null reference value x, x.equals(null) should return false.
Can anyone help me explain what how these instructions affect my code so far/help with pseudocode? I'm confused about what it's asking for. This is my code:
The instructions are correct; you must override equals(). Start by reading its documentation. There are six things there, apart from the bit about hashCode. I know you can only see five, but I can see six. Maybe if I write them out differently, they might be easier to understand:-
Now the equals() method is notorously difficult. You would do well to read the three references I usually quote: look in this old post, and you will find Bloch, Langer, and Odersky Spoon and Venners linked to. There used to be a sample chapter of Bloch's Effective Java (chapter 3, old edition) with a section about the equals method in. You can probably find it if you search hard. Most of what the links say overlaps, but each of the three says a few things the other two don't. That shou&wj;ld guide you in writing an equals method. If you are making subclasses of Part, then you cannot add fields which are used to compare equality and maintain the general contract of equals. So I have a bit of a rule of thumb: equals method means no new fields in subclasses.
Find the src.zip file in your Java® installation folder and unzip it. Read the equals() method in a few classes which have overridden it. Also unzip the java folder then util then the Object.java file and read its equals method.
Let's imagine I have a class Foo with an int field and a String field. Remember the String field might be null, but not the int field. So I might write hashCode like this:-Of course, when you find there is a hash() method in the Objects class and how much easier that is to use, it will be
return Objects.hash(name, number);
No‑brainer It shouldn't take you long to find a method in the Objects class which will simplify lines 7‑8 no end. You do need both pairs of () for the casts.
The @Override annotation will catch if you have overloaded those methods rather than overriding them.
Have a look at your toString method which at a 1‑second look seems all right. If not, it should be child's play to correct compared to equals().
Campbell Ritchie wrote:I forgot to say: line 4 tests for reflexivity, and line 5 tests for non‑nullity. If you pass null to instanceof, it will evaluate to false and the rest of the method is skipped because of the behaviour of &&. Note the first two tests in that method must go in that order.
Got it to work:
First: the signature of the method must be .
And line 12 in your posted code is pointless... you call the equals() method from the superclass and then ignore its result.
And despite talk of "nullity" earlier in the post, you haven't checked the parameter for nullity and as a result you will get NullPointerException thrown if the parameter is null.