This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I just started finally learning OOP in my Java course.One of the first things has been about Overriding, when i use @Override before a method in a subclass,i am actually saying add from the Super class to the sub class correct? In my book it is saying overwrite , but i don't think that is a correct term of what i see happening.
i'm not sure, but I think the @Override is nothing more than an annotation - it is not ever required.
However, if you use it, the compiler knows that you are trying to override a method in the parent class, and will let you know if you have a wrong set of parameters or even simply misspell the name. If the parent class has a 'doStuff' method, and in your child class you create a 'dostuff' method, without the @Override your code compiles but you have two separate methods which may be hard to find. However, if you had the @Override, it would complain at compile time that something was amiss...
It doesn't cause the method to be pulled down from the parent - you get that for free from the 'extends Parent'.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Thanks for your quick answers, in the first set of samples the toString() method is annotated with @Override in the parent and child class, and the output from both classes was then written all together.
I think that the toString() is a special case maybe?
Joined: Sep 28, 2010
Compile and run it with the annotation. Then compile and run it without the annotation. Nothing will change.
Now put the annotation back in, but change the name of the toString method to something else: toStringSpelledWrong(). Compile. What happens?
ok it worked properly without the annotation,but then...why do i bother with it? and with it but one of the methods spelled differently i got "The method toforkString() of type ElternBear must override or implement a supertype method" So there must be two same named methods in the parent and child class correct?
You bother with it because it helps catch mistakes. If you think you're supposed to be overriding a method, but for some reason you're not, then the compiler will complain. Getting the compiler to complain when you make a mistake is a big part of designing a robust programming environment!
If you intend a method to be overriding a method from a superclass, it is always a good idea to use the @Override annotation - this will protect you from unintentionally not overriding a method from the superclass.
A typical example is the hashCode() method. There's a hashCode() method in class Object, and in many situations you want to override it. It's easy to forget that it's called hashCode() with a capital C; you might accidentally write hashcode() with a lower-case c. If you're not using the @Override annotation, then at compile time the compiler will not notice that you made a mistake, and your program might appear to work correctly - but it does contain a bug. Had you used the annotation, like this:
then the compiler would have reported an error, because hashcode() is not actually overriding hashCode() from class Object as you intended.
So, it's meant to prevent you from making mistakes.