There was a design decision to make early on in Java:
Are arrays primitives? or are they Objects?
The answer is, neither really... or both if you look at it another way. They work fairly closely with the system itself and the backend of the jvm.
One example of this is the java.lang.System.arraycopy() method which needs to take an array of any type. Thus, the array needs to be able to inherit something and thats an Object. And arraycopy is a native method.
Arrays are also funny in that they can hold primitives (int, char, double, etc... while the other collections can only hold Objects. Look, for example, at java.util.Arrays and the ugly of the equals methods. This was put in as an after thought. deepEquals(Object[], Object[]) wasn't added until 1.5 while the rest of the Arrays class was added in 1.2.
Because these objects are arrays, they let you do some things that are at the memory or near memory level - something that Java often hides from the coder. This allows certain things to be done faster at the expense of mostly breaking the object model.
There was a trade off early in the system between flexibility and some performance. Performance won out and the lack of flexibility was wrapped in the various collections. Arrays in Java are a thinly implemented Object on top of a primitive type (originally) intended for working with the system when you need it.
For the most part, raw arrays were things that it appears that the original designers tried to ignore and tuck away only in the system. And they wanted it to be fast (early Java had some issues with speed). It was a wart on the design that arrays aren't nice Arrays, but its one that was needed when you wanted to expose something as close to the system as possible. For that matter, the contemporary languages of early Java also have this wart - one can't do a .equals() on C++'s array.
Java and C++ both took the same path for arrays - an external library that does the operations as needed on arrays rather than Arrays... and suggesting the coders to use better, native types unless they really know what they are doing and why they are doing it that way.
Thus, the approach implanting .equals in an array is wrong, but its the same wrong that coders coming from C++ knew of. So chose the least wrong thing in terms of the performance - leave it as the implementation of Object: two Objects are equal if and only if they are referring to the same object.
You need the array to be a primitive like structure for being able to communicate with native bindings - something as close to the classic C array as possible. But unlike the other primitives, you need the array to be able to be passed as a reference, and thus an Object. So its more of a primitive with some Object hacks on the side and some bounds checking.
Remember inheritance defines a "is a" kind of relationship. The code
class Position2D extends Vector2D
tells the compiler that every Position2D is a Vector2D, but not vice versa.
Check out the following examples assuming that you already made the above declaration:
// obviously okay, type of instance matches reference type
Vector2D vecVecRef = new Vector2D();
Position2D posPosRef = new Position2D();
// this is okay because a Position2D is a Vector2D
Vector2D posVecRef = new Position2D();
// The compiler will not automatically convert a Vector2D to a Position2D
Position2D vecPosRef = new Vector2D(); //Compiler error!
A Position2D variable can never refer to a Vector2D object. If you try typecasting it, the compiler will say "fine...I trust you" but then the JVM will get angry when it actually finds out that you are trying to assign a Vector2D to a Position2D. It will raise a ClassCastException at runtime.
// compiles fine but raises ClassCastException in runtime
Position2D vecPosRef = (Position2D) new Vector2D();
This is because you can only Class cast a subclass into a superclass and not vice versa. So basically, you cannot cast Vector2D to Position2D and you cannot assign it without casting either.
The simplest solution to this problem is to have a constructor defined in your subclass that makes a Position2D object out of a given Vector2D object.
class Position2D extends Vector2D {
Position2D() {
// default stuff
}
Position2D(Vector2D v) {
// you currently don't have the getX and getY methods
// so define them in your superclass
setX(v.getX());
setY(v.getY());
}
}
With that one simple and convenient constructor, you can use code like this:
public class Inheritance {
public static void main(String[] args) {
Position2D pos1 = new Position2D();
Position2D pos2 = new Position2D();
pos1.setX(3);
pos1.setY(4);
pos2.setX(5);
pos2.setY(6);
Position2D pos3 = new Position2D(pos1.add(pos2)); // using constructor
System.out.println(pos3.getX()); // this prints 8.0
}
}
As you can see, this way is much more extensible than rewriting all of the subclass methods.
Best Answer