How to make two objects in Java comparable using "<" or ">"
e.g.
MyObject<String> obj1= new MyObject<String>(“blablabla”, 25);
MyObject<String> obj2= new MyObject<String>(“nannaanana”, 17);
if (obj1 > obj2)
do something.
I've made MyObject class header as
public class MyObject<T extends Comparable<T>> implements Comparable<MyObject<T>>
and created method Comp but all the gain I got is now I can use "sort" on the list of objects, but how can I compare two objects to each other directly? Is
if(obj1.compareTo(obj2) > 0)
do something
the only way?
You cannot do operator overloading in Java. This means you are not able to define custom behaviors for operators such as +, >, <, ==, etc. in your own classes.
As you already noted, implementing Comparable and using the compareTo() method is probably the way to go in this case.
Another option is to create a Comparator (see the docs), specially if it doesn't make sense for the class to implement Comparable or if you need to compare objects from the same class in different ways.
To improve the code readability you could use compareTo() together with custom methods that may look more natural. For example:
boolean isGreaterThan(MyObject<T> that) {
return this.compareTo(that) > 0;
}
boolean isLessThan(MyObject<T> that) {
return this.compareTo(that) < 0;
}
Then you could use them like this:
if (obj1.isGreaterThan(obj2)) {
// do something
}
Using Comparable.compareTo(T) is the only option (or Comparator). The interface only defines that one method (while Comparator adds equals), and it compares this object with the specified object for order. Further, Java does not permit operator overloading (so you won't be able to directly change the operand used for invoking that method; or in fact modify the interface).
It is not the only way. You can implement a Comparator as well. Comparator uses compare() method as oppose to Comparable which uses compareTo() method.
The reason you can't use > or < to compare objects directly is because Java won't know which variable you want to use for the comparison (as there might exist more than one variable in the object).
In order to compare objects, those objects must be comparable. You need to define and tell Java how you want to compare them.
Java collection provides a sort method. However some school does give assignment of asking you to write you own sort methods which ultimately still uses the compareTo() for comparison.
You can take a look on the subtle differences between Comparable vs Comparator here: What is the difference between compare() and compareTo()?
I think it is also worth mentioning that, by default Java compares String (objects) in a lexicographical order if you did not override the compareTo() method.
I would advocated that readability must be a primer for us as developers.
Apache Commons Lang (commons-lang) provides a simple fluent utility which reads a lot clearer:
if (is(obj1).greaterThan(obj2)) {
// do something
}
Note: is is shorthand for ComparableUtils.is which can be imported the following this static import statement:
import static org.apache.commons.lang3.compare.ComparableUtils.is;
Related
I want to use a HashSet to store some objects:
public class StoredObject{
Type type; //Type is an enum
//other fields
Type getType(){return type;}
}
Now, I want to store only one StoredObject of the same Type, so I override contains() in a subclass of HashSet:
public MySet<E extends StoredObject> extends java.util.HashSet<E>{
#Override
public boolean contains(Object o) {
if(StoredObject.class.isAssignableFrom(o.getClass())) {//if o implements StoredObject
for(StoredObject s : this) {
if(s.getType() == ((StoredObject) o).getType()) return true;
}
}
return false
}
}
Before this I wanted to use HashSet and modify the equals() of StoredObject. However, the way above seems like a shorter and safer way, especially as in my case the stored objects all implement an interface and don't extend the same class.
Now my question: Is this implementation safe? I tried to search for things it could break, but did not find any. I read that overriding equals() can break Collections.
Also, does this subclass defeats the purpose of an HashSet, since it does not use the HashMap for contains()?
HashMap<Type,StoredObject> is the appropriate collection for this.
If you override equals(Object) then you must also override hashCode (it's also not a bad idea to make it implement Comparable and perhaps override toString). Use the #Override annotation to ensure you have the right parameter types and spelling - very easy to get wrong and confusing to debug.
What can go wrong?
There's a lot of methods in HashSet to override, so that's a lot of work.
More methods may be added to HashSet in future versions of Java - how are you going to look out for this?
contains should be an O(1) operation (assuming a good distribution of hash codes), but the OP implementation is O(n).
Set.equals on another Set will report incorrect results.
Note also that StoredObject.class.isAssignableFrom(o.getClass()) is better written as o instanceof StoredObject (assuming you've got isAssignableFrom the right way around).
Is this implementation safe?
Absolutely not. There are other methods on HashSet that wouldn't work correctly, e.g. add(), leaving the size of the set incorrect.
Besides, that implementation would totally ruin the performance of the contains method, making it run in O(n) instead of O(1).
If you need a Set with a definition of equality that differs from the objects natural definition as implemented by equals() and hashCode(), use a TreeSet and supply a custom Comparator.
class MySet<E extends StoredObject> extends java.util.TreeSet<E> {
public MySet() {
super(Comparator.comparing(StoredObject::getType));
}
}
I do agree with Tom Hawtin - tackline, that HashMap<Type, StoredObject> is a better option, because it allows you to get the StoredObject for a given Type, which is otherwise very difficult to do with a Set. It also allows you to check for existence given just a Type, without having to create a dummy StoredObject object for the check.
I wanted to ask why we use the comparable interface in java? Wouldn't it be simpler to just make the compareTo method without using the comparable interface?
Instead of doing this:
//some class that implements comparable
public int compareTo(someClass someInstanceOfThatClass) {
// do stuff that returns -1,0,or 1
}
Why can't we just do this:
//some class that does NOT implement comparable, but we still
//make a compareTo method
public int compareTo(someClass someInstanceOfThatClass) {
// do stuff that returns -1,0, or 1
}
I guess my question is why do we bother implementing comparable, if we could just make a compareTo method without being forced to by some interface (comparable)?
Comparable is an interface, hence it imposes a contract that others may follow. For example, calling Collections.sort(list) only works if the elements are instances of Comparable, and internally relies on the compareTo method to implement the sorting.
Java's type system is nominal, not structural, so simply having the method required by the interface is not enough to implement it; you also have to declare that the class implements the interface. In some other languages such as Typescript, having the method with the right signature would be enough, but Java is not like that.
If you are only calling the compareTo method from your own code then this may not matter, but if you are using classes or methods from the standard library or from other libraries which take Comparable things as arguments, then your class will need to implement the interface so you can pass your objects to them.
I think it returns to the innate concept of the interface.
You always sure that every class which has implemented Comparable interface, has ability to be compared and sometimes you need this assurance.
For example if you have a method that have a parameter with Comparable type, then you are sure that comapreTo is implemented with that parameter and this parameter issemantically comparable.
But whitout interface you can't get this assurance.
The code my team is working on has several classes where equals and hashCode are not defined in the class hierarchy. We'd like to implement Comparable such that compareTo is consistent with equals using hashCode, like so:
class MyClass implements Comparable<MyClass>
{
private String myProperty;
// Other properties, etc.
....
public int compareTo(MyClass obj) {
// Natural ordering comparisons
...
// Reach here if natural ordering properties are equivalent
return new Integer(this.hashCode()).compareTo(new Integer(obj.hashCode());
}
}
Is this considered a valid means of implementing Comparable? Are there any pitfalls with using the default hashCode implementation that I should be aware of?
UPDATE: The behavior we're striving for is as follows:
The class properties are compared first, in a natural ordering we define.
If a given property for the two objects are equivalent, we move on to the next one in the ordering.
If all properties are equivalent, we return 0 only if this.equals(obj).
Yes this is a valid way. Apparently you want a fixed ordering for objects which are equal on other values (am I right? You did not explain your aim with the hashcode usage here).
The only thing i would do is copy the java code of Integer.compareTo() in your compareTo method, so you do not have to create 2 Integers for every comparison.
No, This is not the valid means of implementing Comparable. Because , suppose your all natural ordering comparison for two different objects of MyClass within equals method comes true , after that when hashcode of two objects are compared it would return false . This is so because in this case hashcode method of Object class would be called by default(as you have not provided your own hashcode method), Which will be different for different objects. Hence the two objects of MyClass will never be equal no matter if all natural ordering comparison comes out to be true.
I've been trying to learn the comparable class for sometime now, I know the correct syntax and the how it is used in most cases. Such as:
int result = ObjectA.compareTo(ObjectB);
would return a value of 0 if both object is the same; a negative value if object A is less then object B ,or a positive value if A is greater then B.
However when I go to actually write a program that uses the compareTo method, the compiler is saying that it can not find the compareTo method.
my question is: Do I have to directly inherit from the Comparable class in order to use the compareTo method? only reason I'm asking is because you do not have to explicitly inherit methods like toString or equals...because everything inherit from object. Where does CompareTo fall under?
You need to implement the Comparable interface:
public class MyClass implements Comparable<MyClass>
and then declare the compareTo() method:
public int compareTo(MyClass myClass){
//compare and return result
}
Comparable is an interface, not a class. So you would implement the interface, not subclass the class. Additionally, implementing the interface means implementing the compareTo method yourself in your implementing class.
First, it will only work in instances. Don't know if your compare is comparing objects or the classes itself because of your naming. I will assume you are using objects :)
The class you want to compare using #compareTo MUST implement Comparable. Another way to achieve this without having to implement Comparable is providing your sort method a Comparator expecting your class.
Comparable is an interface so you do not "inherit" it (extends), but implement it (implements).
You can write your own compareTo method in your class without specifying the Comparable interface, but then the methods in the API won't know if your object meets the contract that Comparable enforces. So, you won't be able to use methods like Arrays.sort() and the like that expect to work with objects that do enforce Comparable.
If you want the objects of your class A compared, possibly because you like to sort a list of those objects, you need to make the class A implement Comparable interface.
Once the class A implements Comparable it must implement and define the behavior of compareTo, which is essentially how you want two objects of class A be compared.
It it this method where you can decide which fields of the class A take part in evaluating the lesser- or greaterness of an object.
I see code like this
class A implements Comparable<A> {
}
What does this mean, what are the advantages and disadvantages of it?
It means that class is committed to respond to the methods defined by the "interface" Comparable.
The advantage you have with this ( and any other "implements" declaration ) it that you can "abstract" the type of the object and code to the interface instead.
Consider this
class A implements Comparable {
....
}
class B implements Comparable {
....
}
class C implements Comparable {
....
}
You then may code something that can use Comparable instead of a specific type:
public void doSomethingWith( Comparable c ) {
c.compareTo( other ); // something else...
}
And invoke it like:
doSomethingWith( new A() );
doSomethingWith( new B() );
doSomethingWith( new C() );
Because you don't really care what the type of the class is, you just care it does implement the interface.
This ( program to the interface rather to the implementation ) is one of the most powerful techniques in OO programming world, because it promotes low-coupling.
Implementing a comparable interface means that A can be compared with other instances of A.
Many operations in java that involve sorting use the methods defined in the Comparable interface to determine if instances of A are greater then less or equal to other instances.
By implementing these methods you are able to use a lot of handy features such as java sort, use instances of A as keys for binary trees, and more.
It means that class A can be sorted using the Comparable compareTo method:
A a1 = new A(1);
A a2 = new A(3);
// -1, 0, or 1 depending on whether a2 is less than, equal to, or greater than a1
int order = a1.compareTo(a2);
Comparable uses the natural ordering for your class.
Another way to go since Java 5 is Comparator. You can pass this object around and have more than one way to compare and sort the target class. For example, sometimes you might want to sort a Name class by first name, other times by last name. Comparable only gives you one way to do it, but you can have several Comparator instances.
It means that the class is one which can be operated on by functions which expect their arguments to be objects that can be compared with other objects of the same type (such as the pre-defined sorting functionality for lists).
Implementing the Comparable interface means that the class supports certain functions which the interface requires (specifically, the compareTo() method), that the sorting (or other) operations being performed on the class will utilize to do their work without having to care about the rest of the class.
For more details:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html
In addition to what everyone else said, by implementing an interface (or extending a class), you get compiler enforcement of the contract of the supertype. In the case of 'Comparable', that means that you get a compiler error if you fail to implement the 'int compareTo(A anA)' method in the implementing class. Adding the annotation '#Override' to the implementing method provides even more compile-time safety; if you fail to implement the method with the right signature the compiler will tell you. Compile-time errors are much, much easier and cheaper to fix than run-time errors. Furthermore, implementing an interface allows any instance of an implementing class to be treated as the interface type for methods (and constructors) that take the interface type as an argument or generic parameter. For example, the 'java.util.Collections.max(Collection coll)' method takes a collection whose base type must extend 'Comparable'.
http://download.oracle.com/javase/7/docs/api/java/util/Collections.html#max(java.util.Collection)
It means that objects of this class can be easily sorted in collections because they can be compared to each other. The other option is to implement a Comparator which is a class responsible for sorting other classes. The Comparable puts the sorting logic directly in the class to be sorted; the Comparator puts the sorting logic in a different class.