In AP Computer Science A, an overriding method is a method in a subclass with the same name, parameter list, and compatible return type as a method in its superclass, giving the subclass its own implementation that runs instead of the inherited version.
An overriding method is how a subclass says "thanks for the inherited behavior, but I'm going to do this my way." When a subclass declares a method with the same name, the same parameter list, and a compatible return type as a method in its superclass, the subclass version overrides the inherited one. Any object of the subclass type will run the new version, even when the object is stored in a superclass variable. That last part is the whole point. It's what makes polymorphism work in Java.
There are rules. The signature (name + parameters) must match exactly. The return type must match, or be a subclass of the original return type. And the access level can't get more restrictive, so a public method in the superclass can't be overridden as private in the subclass. The compiler will reject it. If you still need the original behavior, you can call it from inside the override with super.methodName(). Java also gives you the @Override annotation, which tells the compiler "I intend to override here, yell at me if I got the signature wrong."
Overriding lives in Unit 9 (Inheritance), where the course builds class hierarchies with extends and then asks what actually happens when you call a method on an object. Overriding is the mechanism behind dynamic (run-time) method dispatch. Java picks the method based on the object's actual type, not the variable's declared type. That one idea powers most of the trickiest inheritance MCQs and is required knowledge for class-design FRQs where you extend a given superclass. It also reinforces Unit 5 skills, because you can't override correctly if you don't have method signatures, parameters, and return types down cold.
Overloading a method (Units 5 & 9)
Overriding's evil twin. Overloading is same name, different parameter list, all in one class. Overriding is same name, same parameter list, across a superclass-subclass pair. Change the parameters in the subclass and you've accidentally overloaded instead of overridden, and the superclass version is still live.
Superclass and the super keyword (Unit 9)
Overriding doesn't delete the superclass method. It hides it for subclass objects. Inside the overriding method, super.methodName() reaches back up and runs the original, which is the standard pattern when the subclass wants to add behavior rather than fully replace it.
Polymorphism (Unit 9)
Overriding is what polymorphism cashes in on. If Animal a = new Dog(); and Dog overrides makeSound(), then a.makeSound() runs the Dog version. Java decides at run time based on the object, not the variable type. Tracing this is one of the most common Unit 9 MCQ tasks.
Method signatures and return types (Unit 5)
Whether something counts as an override comes down to Unit 5 fundamentals. The name and parameter list must match exactly, and the return type must be the same or a subclass of the original (a String return can override an Object return, since String is-an Object).
Multiple-choice questions love to test the rules by showing you code that looks like an override and asking whether it compiles or what it prints. Watch for three classic traps. First, narrowed access: a subclass declaring a private version of a protected superclass method is a compile error, not a valid override. Second, return types: an override can return the same type or a subclass of it, so String getValue() can legally override Object getValue(). Third, polymorphic calls: a superclass reference pointing to a subclass object runs the overridden subclass version. You should also know that super.methodName() is how an overriding method calls the superclass version. On the free-response side, the class-design FRQ regularly hands you a superclass and asks you to write a subclass, and overriding a method (often with a super call inside) is frequently part of full credit.
Overriding means a subclass redefines an inherited method with the exact same signature, and the choice of which version runs happens at run time based on the object's actual type. Overloading means one class has multiple methods with the same name but different parameter lists, and the compiler picks the right one at compile time based on the arguments. Quick check: same signature across two classes is overriding; different parameters in the same class is overloading.
An overriding method has the same name and parameter list as a superclass method, and its return type must be the same or a subclass of the original.
An override cannot make access more restrictive, so overriding a public method as private (or protected as private) is a compile-time error.
When a superclass variable holds a subclass object, calling an overridden method runs the subclass version because Java dispatches based on the object's actual type at run time.
Use super.methodName() inside an overriding method to call the superclass version, which is the standard way to extend behavior instead of replacing it.
The @Override annotation is optional but catches mistakes, because the compiler errors if the method below it doesn't actually override anything.
If you change the parameter list, you're overloading, not overriding, and the superclass method is still inherited and callable.
It's a method in a subclass with the same name, same parameter list, and compatible return type as a superclass method, giving the subclass its own implementation. It's tested in Unit 9 (Inheritance) and is the mechanism behind polymorphism.
Overriding keeps the exact same signature across a superclass and subclass, and the version that runs is decided at run time. Overloading uses the same name with different parameter lists in the same class, resolved at compile time. Same signature, two classes = overriding; different parameters, one class = overloading.
Only in the widening direction. The override can't be more restrictive (public can't become private), and the return type must be the same or a subclass of the original. A String return can override an Object return, but not the reverse.
No. The superclass method still exists, and the overriding method can call it with super.methodName(). The override just becomes the version that runs for objects of the subclass type.
No, overriding works without it. But @Override makes the compiler verify the signature matches a superclass method, so a typo or wrong parameter list becomes an error instead of a silent accidental overload. Use it anyway.