What is method overriding in java?

Answer 1

Method overriding is when a child class redefines the same method as a parent class, with the same parameters.

For example, the standard Java class java.util.LinkedHashSet extends java.util.HashSet. The method add() is overridden in LinkedHashSet. If you have a variable that is of type HashSet, and you call its add() method, it will call the appropriate implementation of add(), based on whether it is a HashSet or a LinkedHashSet. This is called polymorphism.

Method overloading is defining several methods in the same class, that accept different numbers and types of parameters. In this case, the actual method called is decided at compile-time, based on the number and types of arguments. For instance, the method System.out.println() is overloaded, so that you can pass ints as well as Strings, and it will call a different version of the method.

Overriding is an example of run time polymorphism. The JVM does not know which version of method would be called until the type of reference will be passed to the reference variable. It is also called Dynamic Method Dispatch.

Overloading is an example of compile time polymorphism.

Answer 2

Overloading - same method name, different method arguments and / or returned type.

Example:

public class EX {

public void M() {}

public void M(int k) {}

public virtual void V() {}

}

The method M() above has an overloaded method M(int k)

Overriding: override (or overwrite) the implementation of a particular method (same method signature - that is, same return type, same name, and the same arguments and their types).

Example:

public class DR : EX

{

public new void M() {} // force to override, a variation

public override void V() {} // the usual override

}

The methods M and V of DR override the implementation in EX.

Answer 3

overloading is the ability to define more than one method with the same name in the same class with different method signatures is part of the method declaration. It is the combination of the method name and the parameter list. class overloadDemo { int c;

public int add(int a,int b) { c=a+b; System.out.println("add="+c);

}

public int add(int a, int b, int d);

{ this.add(5,6);

c=a+b+d; System.out.println("add="+c);

}

public static void main(String arg[]) { int a=5,b=6,d=10;

overloadDemo as=new overloadDemo(); as.add(5,6,10);

}

}

Answer 4

Overridden Methods

Any time you have a class that inherits a method from a superclass, you have the opportunity to override the method (unless, as you learned in the earlier chapters, the method is marked final). The key benefit of overriding is the ability to define behavior that's specific to a particular subclass type. The following example demonstrates a Porsche subclass of Car overriding the Car version of the drive() method:

public class Car {

public void drive() {

System.out.println("Generic Car Driving Generically");

}

}

class Porsche extends Car {

public void drive() {

System.out.println("Porsche driving Full Throttle");

}

}

For abstract methods you inherit from a superclass, you have no choice. You must implement the method in the subclass unless the subclass is also abstract. Abstract methods must be implemented by the concrete subclass, but this is a lot like saying that the concrete subclass overrides the abstract methods of the superclass. So you could think of abstract methods as methods you're forced to override.

The Car class creator might have decided that for the purposes of polymorphism, all Car subtypes should have an drive() method defined in a unique, specific way. Polymorphically, when someone has an Car reference that refers not to an Car instance, but to an Car subclass instance, the caller should be able to invoke drive() on the Car reference, but the actual runtime object (say, a Porsche instance) will run its own specific drive() method. Marking the drive() method abstract is the Car programmer's way of saying to all subclass developers, "It doesn't make any sense for your new subtype to use a generic drive() method, so you have to come up with your own drive() method implementation!" A (non-abstract), example of using polymorphism looks like this:

public class TestCars {

public static void main (String [] args) {

Car a = new Car();

Car b = new Porsche(); //Car ref, but a Porsche object

a.drive(); // Runs the Car version of drive()

b.drive(); // Runs the Porsche version of drive()

}

}

class Car {

public void drive() {

System.out.println("Generic Car Driveing Generically");

}

}

class Porsche extends Car {

public void drive() {

System.out.println("Porsche driving Full Throttle");

}

public void brake() { }

}

In the preceding code, the test class uses a Car reference to invoke a method on a Porsche object. Remember, the compiler will allow only methods in class Car to be invoked when using a reference to a Car. The following would not be legal given the preceding code:

Car c = new Porsche();

c.brake(); // Can't invoke brake();

// Car class doesn't have that method

To reiterate, the compiler looks only at the reference type, not the instance type. Polymorphism lets you use a more abstract supertype (including an interface) reference to refer to one of its subtypes (including interface implementers).

The overriding method cannot have a more restrictive access modifier than the method being overridden (for example, you can't override a method marked public and make it private). Think about it: if the Car class advertises a public drive() method and someone has an Car reference (in other words, a reference declared as type Car), that someone will assume it's safe to call drive() on the Car reference regardless of the actual instance that the Car reference is referring to. If a subclass were allowed to sneak in and change the access modifier on the overriding method, then suddenly at runtime-when the JVM invokes the true object's (Porsche) version of the method rather than the reference type's (Car) version-the program would die a horrible death. Let's modify the polymorphic example we saw earlier in this section:

public class TestCars {

public static void main (String [] args) {

Car a = new Car();

Car b = new Porsche(); //Car ref, but a Porsche object

a.drive(); // Runs the Car version of drive()

b.drive(); // Runs the Porsche version of drive()

}

}

class Car {

public void drive() {

System.out.println("Generic Car Driveing Generically");

}

}

class Porsche extends Car {

private void drive() { // whoa! - it's private!

System.out.println("Porsche driving Full Throttle");

}

}

If this code compiled (which it doesn't), the following would fail at runtime:

Car b = new Porsche(); // Car ref, but a Porsche

// object , so far so good

b.drive(); // Chaos at runtime!

The variable b is of type Car, which has a public drive() method. But remember that at runtime, Java uses virtual method invocation to dynamically select the actual version of the method that will run, based on the actual instance. A Car reference can always refer to a Porsche instance, because Porsche IS-A Car. What makes that superclass reference to a subclass instance possible is that the subclass is guaranteed to be able to do everything the superclass can do. Whether the Porsche instance overrides the inherited methods of Car or simply inherits them, anyone with a Car reference to a Porsche instance is free to call all accessible Car methods. For that reason, an overriding method must fulfill the contract of the superclass.

The rules for overriding a method are as follows:

• The argument list must exactly match that of the overridden method. If they don't match, you can end up with an overloaded method that you didn't intend on creating.

• The return type must be the same as, or a subtype of, the return type declared in the original overridden method in the superclass.

• The access level can't be more restrictive than the overridden method's. (public to private not allowed)

• The access level CAN be less restrictive than that of the overridden method. (private to public allowed)

• Instance methods can be overridden only if they are inherited by the subclass. A subclass within the same package as the instance's superclass can override any superclass method that is not marked private or final. A subclass in a different package can override only those non-final methods marked public or protected (since protected methods are inherited by the subclass).

• The overriding method CAN throw any unchecked (runtime) exception, regardless of whether the overridden method declares the exception.

• The overriding method must NOT throw checked exceptions that are new or broader than those declared by the overridden method. For example, a method that declares a FileNotFoundException cannot be overridden by a method that declares a SQLException, Exception, or any other non-runtime exception unless it's a subclass of FileNotFoundException.

• The overriding method can throw narrower or fewer exceptions. Just because an overridden method "takes risks" doesn't mean that the overriding subclass' exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares.

• You cannot override a method marked final.

• You cannot override a method marked static.

• If a method can't be inherited, you cannot override it. Remember that overriding implies that you're re-implementing a method you inherited! For example, the following code is not legal, and even if you added an drive() method to Porsche, it wouldn't be an override of Car's drive() method.

public class TestCars {

public static void main (String [] args) {

Porsche h = new Porsche();

h.drive(); // Not legal because Porsche didn't inherit drive()

}

}

class Car {

private void drive() {

System.out.println("Generic Car Driveing Generically");

}

}

class Porsche extends Car { }

Invoking a Superclass Version of an Overridden Method

Often, you'll want to take advantage of some of the code in the superclass version of a method, yet still override it to provide some additional specific behavior. It's like saying, "Run the superclass version of the method, then come back down here and finish with my subclass additional method code." It's easy to do in code using the keyword super as follows:

public class Car {

public void drive() { }

public void changeGear() {

// Useful change gear code goes here

}

}

class Porsche extends Car {

public void changeGear() {

// Take advantage of Car code, then add some more

super.changeGear(); // Invoke the superclass (Car) code

// Then do Porsche-specific change gear work here

}

}

Note: Using super to invoke an overridden method only applies to instance methods. (Remember, static methods can't be overridden.)

If a method is overridden but you use a polymorphic (supertype) reference to refer to the subtype object with the overriding method, the compiler assumes you're calling the supertype version of the method. If the supertype version declares a checked exception, but the overriding subtype method does not, the compiler still thinks you are calling a method that declares an exception. Let's take a look at an example:

class Car {

public void drive() throws Exception {

// throws an Exception

}

}

class Car2 extends Car {

public void drive() { /* no Exceptions */}

public static void main(String [] args) {

Car a = new Car2();

Car2 d = new Car2();

d.drive(); // ok

a.drive(); // compiler error - unreported exception

}

}

This code will not compile because of the Exception declared on the Car drive() method. This happens even though, at runtime, the drive() method used would be the Car2 version, which does not declare the exception.

Examples of Illegal Method Overrides

Let's take a look at overriding the drive() method of Car:

public class Car {

public void drive() { }

}

Let us take a look at a few examples of overridden drive() methods taking the above version of the method in the Car Class

1. private void drive() {} - Access Modifier is more restrictive

2. public void drive() throws IOException {} - Declares a checked exception that is not defined by the super class

3. public void drive (String road) {} - A legal overload but not an override because the arguments to the method has changed (Don't bother about overload just yet, that is the next paragraph)

4. public String drive() {} - Not an override because of the return type and at the same time, not an overload either because there is no change in the argument list.

Answer 5

Overridden Methods

Any time you have a class that inherits a method from a superclass, you have the opportunity to override the method (unless, as you learned in the earlier chapters, the method is marked final). The key benefit of overriding is the ability to define behavior that's specific to a particular subclass type. The following example demonstrates a Porsche subclass of Car overriding the Car version of the drive() method:

public class Car {

public void drive() {

System.out.println("Generic Car Driving Generically");

}

}

class Porsche extends Car {

public void drive() {

System.out.println("Porsche driving Full Throttle");

}

}

For abstract methods you inherit from a superclass, you have no choice. You must implement the method in the subclass unless the subclass is also abstract. Abstract methods must be implemented by the concrete subclass, but this is a lot like saying that the concrete subclass overrides the abstract methods of the superclass. So you could think of abstract methods as methods you're forced to override.

The Car class creator might have decided that for the purposes of polymorphism, all Car subtypes should have an drive() method defined in a unique, specific way. Polymorphically, when someone has an Car reference that refers not to an Car instance, but to an Car subclass instance, the caller should be able to invoke drive() on the Car reference, but the actual runtime object (say, a Porsche instance) will run its own specific drive() method. Marking the drive() method abstract is the Car programmer's way of saying to all subclass developers, "It doesn't make any sense for your new subtype to use a generic drive() method, so you have to come up with your own drive() method implementation!" A (non-abstract), example of using polymorphism looks like this:

public class TestCars {

public static void main (String [] args) {

Car a = new Car();

Car b = new Porsche(); //Car ref, but a Porsche object

a.drive(); // Runs the Car version of drive()

b.drive(); // Runs the Porsche version of drive()

}

}

class Car {

public void drive() {

System.out.println("Generic Car Driveing Generically");

}

}

class Porsche extends Car {

public void drive() {

System.out.println("Porsche driving Full Throttle");

}

public void brake() { }

}

In the preceding code, the test class uses a Car reference to invoke a method on a Porsche object. Remember, the compiler will allow only methods in class Car to be invoked when using a reference to a Car. The following would not be legal given the preceding code:

Car c = new Porsche();

c.brake(); // Can't invoke brake();

// Car class doesn't have that method

To reiterate, the compiler looks only at the reference type, not the instance type. Polymorphism lets you use a more abstract supertype (including an interface) reference to refer to one of its subtypes (including interface implementers).

The overriding method cannot have a more restrictive access modifier than the method being overridden (for example, you can't override a method marked public and make it private). Think about it: if the Car class advertises a public drive() method and someone has an Car reference (in other words, a reference declared as type Car), that someone will assume it's safe to call drive() on the Car reference regardless of the actual instance that the Car reference is referring to. If a subclass were allowed to sneak in and change the access modifier on the overriding method, then suddenly at runtime-when the JVM invokes the true object's (Porsche) version of the method rather than the reference type's (Car) version-the program would die a horrible death. Let's modify the polymorphic example we saw earlier in this section:

public class TestCars {

public static void main (String [] args) {

Car a = new Car();

Car b = new Porsche(); //Car ref, but a Porsche object

a.drive(); // Runs the Car version of drive()

b.drive(); // Runs the Porsche version of drive()

}

}

class Car {

public void drive() {

System.out.println("Generic Car Driveing Generically");

}

}

class Porsche extends Car {

private void drive() { // whoa! - it's private!

System.out.println("Porsche driving Full Throttle");

}

}

If this code compiled (which it doesn't), the following would fail at runtime:

Car b = new Porsche(); // Car ref, but a Porsche

// object , so far so good

b.drive(); // Chaos at runtime!

The variable b is of type Car, which has a public drive() method. But remember that at runtime, Java uses virtual method invocation to dynamically select the actual version of the method that will run, based on the actual instance. A Car reference can always refer to a Porsche instance, because Porsche IS-A Car. What makes that superclass reference to a subclass instance possible is that the subclass is guaranteed to be able to do everything the superclass can do. Whether the Porsche instance overrides the inherited methods of Car or simply inherits them, anyone with a Car reference to a Porsche instance is free to call all accessible Car methods. For that reason, an overriding method must fulfill the contract of the superclass.

The rules for overriding a method are as follows:

• The argument list must exactly match that of the overridden method. If they don't match, you can end up with an overloaded method that you didn't intend on creating.

• The return type must be the same as, or a subtype of, the return type declared in the original overridden method in the superclass.

• The access level can't be more restrictive than the overridden method's. (public to private not allowed)

• The access level CAN be less restrictive than that of the overridden method. (private to public allowed)

• Instance methods can be overridden only if they are inherited by the subclass. A subclass within the same package as the instance's superclass can override any superclass method that is not marked private or final. A subclass in a different package can override only those non-final methods marked public or protected (since protected methods are inherited by the subclass).

• The overriding method CAN throw any unchecked (runtime) exception, regardless of whether the overridden method declares the exception.

• The overriding method must NOT throw checked exceptions that are new or broader than those declared by the overridden method. For example, a method that declares a FileNotFoundException cannot be overridden by a method that declares a SQLException, Exception, or any other non-runtime exception unless it's a subclass of FileNotFoundException.

• The overriding method can throw narrower or fewer exceptions. Just because an overridden method "takes risks" doesn't mean that the overriding subclass' exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares.

• You cannot override a method marked final.

• You cannot override a method marked static.

• If a method can't be inherited, you cannot override it. Remember that overriding implies that you're re-implementing a method you inherited! For example, the following code is not legal, and even if you added an drive() method to Porsche, it wouldn't be an override of Car's drive() method.

public class TestCars {

public static void main (String [] args) {

Porsche h = new Porsche();

h.drive(); // Not legal because Porsche didn't inherit drive()

}

}

class Car {

private void drive() {

System.out.println("Generic Car Driveing Generically");

}

}

class Porsche extends Car { }

Answer 6

It means you have different methods with the same name, but a different "signature", that is, a different combination of parameters. For example, the following sample class has sample methods to do multiplication, both with integers and with doubles:

public static class MyMath
{
public static int multiply(int a, int b) {return a * b;}
public static int multiply(double a, double b) {return a * b;}

}

If you invoke the method, for example, with:

System.out.println(MyMath(5, 10));

the compiler will automatically choose the "int" version of the method, because 5 and 10 are recognized as integers. If you change this to ...MyMath(5.0, 10.0)..., the compiler will invoke the "double" version.