Win a copy of Java 9 Revealed this week in the Features new in Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Inheritance project  RSS feed

 
Shal Lango
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Part.java, override these two methods, both inherited from its superclass, Object
toString()
equals()

Two Parts are equal if and only if they have the same:
number
ncage
niin
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:

Part class:

****************
 
Campbell Ritchie
Sheriff
Posts: 54033
130
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a bit missed out: you must override hashCode as well.
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:-
  • 1: Every object is equal to itself. Reflexivity.
  • 2: Iff object1 equals object2 then object2 equals object1. Symmetry.
  • 3: If object1 equals object2 and object2 equals object3 then object1 equals object3. Transitivity.
  • 4: If everything stays the same, then you get the same result. Consistency.
  • 4½: If you always get the same result, then you mustn't let the method throw any exceptions. Consistency again.
  • 5: An object which exists is different from an object which doesn't exist. Non‑nullity.
  • You cannot use the Object#equals method to test whether null == null, but you can use something like Objects#equals(). The convention is to consider that null == null, and comparing two references both pointing to null with Objects#equals produces the result true.

    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 shou‍ld be child's play to correct compared to equals().
     
    Campbell Ritchie
    Sheriff
    Posts: 54033
    130
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Shal Lango
    Ranch Hand
    Posts: 31
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:



    Thank you!
     
    Paul Clapham
    Sheriff
    Posts: 22200
    38
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    There's several things wrong with that.

    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.
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!