Overloading and overriding are two similar concepts -they both are about creating several methods with the same name- but very different when it comes to practical functionality and implementation.
Overloading (formally, static polymorphism) is resolved at compile time, and it is when the methods with the same name are declared in the same class, distinguished only by their signatures (the parameters of the method), so that the compiler knows which method overload you are calling based on the data type of the arguments you are passing.
Overriding (or overwriting, according to ken), is resolved at runtime and it is when you define a method that is already defined in a parent class. It can be resolved because of the data type of the “implicit first parameter” (aka, the object itself).
Overloading with different data types and number of parameters.
Overloading with same data types and number of parameters, but different order.
Overloading allow different return types.
The return type of the method is not considered when overloading.
In this example of overriding I have the Person abstract class, this class cannot be instantiated, but it provides like a “template” for its children classes. For example, the Person class has a String field “name”, because every person has a name, and a public method “talk” because all persons can talk (ok, almost all), this method prints “I’m a ” to the console, because, like I said, this is like a template, and different persons have different (very interesting) things to say. The method “getName” returns the name of the person. The constructor just takes the String name, although you can’t call this constructor directly, it can be called from its children classes.
It’s children classes are not abstract and extend (are children of) the Person class. They implicitly have “name”, a method “talk” and a method “getName”. Read the code of the Student and the Teacher classes and note how the constructors have a line “super(name)”, this is a call to the parent class constructor, and it will throw an error if it’s not there. Both the Student and the Teacher class Override the talk method, the notation @Override over the talk method just tells the compiler that you are overriding a method (no shit, Sherlock), it’s not required but you should use it to enforce proper overriding of a method. The talk() methods of Student and Teacher call the “super.talk” method (unlike the constructor, you can miss this statement here and there will be no errors), it prints “I’m a “, and then it prints something else. I also included an Overload of an Overriding method (mind blown) in the Student class to show the difference, it just prints “I love” + the argument (there is no call to super.talk()).
In the main method of the Person class I declare 2 persons, one teacher and other student, also, I declare a Student as a Student, this sound stupid but actually affects in the code. The preferred way is to declare the variable with the data type of the abstract class and instantiate it as the type that you actually want to use (Declared type on the left and Actual type on the right so your code is not dependent from a specific implementation of an interface/abstract class. You can read more about this here. You can see that when the talk method is called from both the teacher and the student they print different things. Finally, to call the Overload method “talk(String food)” of “s” (with Declared type Person and Actual type Student) you have to implicitly cast it to Student and then call the method, like ((Student)s).talk(“tacos”), this is because this implementation is not declared in the Declared type of “s”. However, with “c” this does not happen, you can call that overload method because the Declared type of “c” is Student. Anyway, this is not considered a good OO practice, you should avoid writing methods that are not in the parent class, because there is a method specific to the Children class, and therefore making the code dependent from that class, and what you want is to make the code independent from specific implementations of the children classes (like explained in the previous stack overflow link).