当我们要重写方法时，为什么要使用接口？

Question

Here we're importing Comparator because the class SizeComparator implements Comparator... - Why not leave out the implements part of comparator if all we want is the compare method, which we are overriding anyway? Since we're overriding it why even type in the code that we want to implement the interface?

Answer 1

I think what you're implying is the effective difference between nominal typing and structural typing.

Structural typing is like this:

• If variable x is an object whose definition so happens to have a method named compare , please invoke it. Otherwise throw something or fail to compile.

Nominal typing is like this:

• Variable x has a type. If that type has a method named compare , invoke it. If x is not that type, or x is but that type does not have a method named compare , throw something, or fail to compile.

Java is nominally typed: You can't just go: "I want to call the compare method on this object". No, the object needs to be of a known type that has a compare method. It's a 2step process: First java checks what the type of some expression is, and then you get to write method calls to methods that this type is declared to have. What the actual object's actual type is, is immaterial. Trivial example:

Object o = new ArrayList<String>();
o.add("Hello");

does not compile - because the compiler notices o. , checks the type of the o expression, finds that it is java.lang.Object , checks what jlObject 's API exposes, notices that there is no add(String) method in there, and fails to compile. Even though at runtime it would have worked . Because o-the-variable is pointing at an object whose real type is something that does have an add method.

The reason that nominal typing is good goes deep, and certainly not all programming languages work that way. It has advantages and disadvantages. For just one simple reason why structural typing can be a bit dangerous, imagine these two classes:

class Camera {
  void shoot(Person p) {}
}

class Gun {
  void shoot(Person p) {}
}

Hopefully that helps you see how structural typing could get problematic. Names are useful. Namespaced names are far more useful - they avoid 'name squatting', where somebody who wrote a camera class thought they could claim the name 'shoot' as did someone writing a gun class. This problem goes away if the language is fundamentally designed that all methods have a complete name, and that name is com.martinhavens.Gun.shoot . Now there is no way to accidentally blow your face off if all you wanted to do, was make a selfie.

In your specific example it is perhaps possible for the system to work without it, given that SizeComparator itself also defines it, but programming is an exercise in abstraction. For example, java's built in java.util.TreeSet class builds a tree set: It can store objects, automatically promises you that it only ever contains 1 of a given value (never duplicates), and it automatically sorts itself. It does this by making a tree structure. To make such a class, you need to provide - A comparator . Obviously, the authors of java-the-core-library cannot know that you have written your own class named SizeComparator . Hence, only 3 options:

• They hardcode every name of every comparison type anybody ever makes for the rest of eternity.
• They use structural typing: It doesn't matter what you pass to the constructor of TreeSet , as long as it is something that has a compare(T a, T b) method. Possible, but java is not like that, and there are advantages to this - see above.
• The authors of TreeSet also publish a type that describes what "code capable of comparing things in the way TreeSet needs to do its job", and then any code anybody else writes with the intention of feeding it to TreeSet's constructor must indicate they are an implementation of this. Which is exactly how java works.