Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What's the difference between Inheritance and Polymorphism?
I'm using Java code as an example, but this can be answered if you don't know Java.
class Bird{
public void sing(){
System.out.println("Testing");
}
}
class anClass extends Bird{
public void sing(){ //If I remove the method than, `c.sing()` in main method (Polymorphism class) will print,"Testing"
System.out.println("Testing second time");
}
}
public class Polymorphism{
public static void main(String[] args){
Bird b = new Bird();
b.sing(); //will print,"Testing"
anClass c = new anClass();
c.sing(); //will print,"Testing second time"
}
}
class numberOne{
public int add(int a, int b){
return a+b;
}
}
class numberTwo extends numberOne{
public int sub(int a, int b){
return a-b;
}
}
public class Inheritance{
public static void main(String[] args){
numberTwo b = new numberTwo();
b.add(5,3); //will print,"8"
c.sub(10,4); //will print,"6"
}
}
I had studied OOP, inheritance and polymorphism before, but I could never really get it.
In the examples above, I noticed that in the polymorphism examples, the methods don't return a value, while in the inheritance examples, they do. Would that be the difference between those two concepts?
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Does Inteheritance actually meant return and Polymorphism meant to print out values?
This doesn't make the slightest sense... Probably you should forget all you've heard - don't "watch tutorials", start over with a good book on the subject written by an actual expert.
To answer the questions, inheritance means what it sounds like - that a class inherits some or all of the methods/members of the parent class.
Polymorphism means that you can have an instance of the inherited class, point to it with a base class pointer, call a method of the base class and then automatically get the derived method called instead.
Example with some generic pseudo-code below. Suppose you have a base class and an inherited class like this:
class Animal
{
MakeNoise() { ... }
}
class Dog : public Animal // whatever the syntax for inheritance is in the given language
{
MakeNoise() { print("Woof") }
}
Now suppose there is a function DoStuff(Animal obj) { obj.MakeNoise() }. If we pass a Dog object to this function, then polymorphism means that "Woof" gets printed even though whoever implemented DoStuff has no idea about the Dog class. When the default behavior gets implicitly replaced by derived behavior, without the need to rewrite the original code, then you have polymorphism.
What does OOP actually mean?
Object Oriented Programming is a way to design programs. There's obviously tonnes of study material about the topic already available, but to summarize it briefly, it roughly consists of 3 things:
-
Private encapsulation. Don't expose internals of a class outside that class. Mainly because none else needs to know about the internals. But also to prevent namespace collisions.
-
Creating autonomous classes with "loose coupling". The class should do it's designated task and only know and depend on the things needed for that task. It shouldn't know or access unrelated things. It should have as few dependencies as possible on other classes. This is to reduce bugs and complexity, and to make code easier to develop and maintain.
-
Inheritance. Designing base class templates that other classes can derive from. This is actually a far less important feature than the others - it is useful in some situations, but should be used with care since it is very hard to predict the future needs of a certain code base in advance.
Then there's various features that makes OO easier, such as constructors/destructors, RAII, member functions with a "this object" and so on. They aren't strictly speaking necessary for OO, but quite handy to have.
What you're asking is a very broad topic, and it'd require entire books to cover everything. For the sake of simplicify, I'll just stick to the basics.
Inheritance
Inheritance can be explained as an "is a" relation, or a specialization of a especific type.
Borrowing (and extending) the example from the other answer, and adapting to Java code, as the question used that language (and also assuming that each class is in its own .java file, as they're all public):
public class Animal {
protected String name; // all animals have a name
public String getName() {
return name;
}
public Animal(String name) { // constructor
this.name = name;
}
public void makeNoise() { // all animals make some noise
System.out.println(this.name + ": making some noise");
}
}
public class Dog extends Animal {
private String breed; // dogs have breeds
public String getBreed() {
return breed;
}
public Dog(String name, String breed) {
super(name);
this.breed = breed;
}
@Override
public void makeNoise() {
System.out.println(this.name + ": woof");
}
}
public class Cat extends Animal {
public Cat(String name) {
super(name);
}
@Override
public void makeNoise() {
System.out.println(this.name + ": meow");
}
}
Both Dog and Cat extend/are subclasses of/inherit from Animal. This means that they inherit some characteristcs of Animal (such as the name field and the respective getter, and the makeNoise method), but they are also specialized types of Animal, because they can override those characteristics - example: each one can have its own makeNoise method, with their own specific implementation (as each animal makes a different kind of noise).
Also note that the Dog adds even more information (the breed field and its respective getter): that's exclusive for dogs, as not all animals have breeds (I know cats also have breeds, but for the sake of this example, I'm pretending they don't).
The @Override annotation instructs the compiler that you're overriding a method, and can show warnings - or errors, depending on how the compiler is configured - if you try to override a method that's not in the superclass. Check here for more info.
It's common to refer to Dog and Cat as subclasses, or child classes, or derived classes of Animal (and Animal is a superclass, or parent class of Dog and Cat).
Different languages will have different rules for what's permitted or forbidden when inheriting classes. For example, some languages allow multiple inheritance (a subclass can extend two or more superclasses), while other languages limit that to just one superclass (which is Java's case).
Polymorphism
Polymorphism means "having many forms". In programming, it's the ability to present the same interface for multiple different types.
Using the classes above, let's suppose I create a method that receives an Animal and calls its makeNoise method:
public static void hear(Animal animal) {
animal.makeNoise();
}
This method accepts an Animal argument, but I can actually pass an instance of any subclass, and it'll work:
hear(new Dog("Rex", "Akita")); // Rex: woof
hear(new Cat("Garfield")); // Garfield: meow
Because both Dog and Cat are subclasses of Animal, the hear method accept them as arguments, and calls their respective specialized versions of the makeNoise method. This is resolved at runtime, and the mechanism is also known as Dynamic Method Dispatch.
In this case I'm not interested in knowing which kind of animal I'm dealing with, I just want to call the makeNoise method, regardless of whatever implementation it has. I could go even further and make a method that receives a list of animals:
// all animals in the list will make their respective noises
public static void hearAll(List<Animal> animals) {
for (Animal animal : animals) {
animal.makeNoise();
}
}
...
// animals list
List<Animal> animals = Arrays.asList(
new Dog("Rex", "Akita"),
new Cat("Garfield"),
... ); // add as many animals as you want
hearAll(animals);
This is a very flexible approach because I could create more Animal subclasses (Duck, Tiger, Dinossaur, etc), and the hear and hearAll methods would still remain the same.
Obviously, if I want to get the dog's breed, then I'd have to know when the instance is a
Dog(perhaps usinginstanceof), but that's beside the point (I said I'd just cover the basics here).
Anyway, the important lesson here is: polymorphism can be achieved with inheritance (without subclasses, all the mechanism above wouldn't be possible). The mechanism described above is also known as subtyping polymorphism.
But there are other types of polymorphism that don't need inheritance. By no means this should be considered an exhaustive list (or even "academically accurate"), but just to mention two examples:
Ad Hoc
In ad hoc (or "compile time") polymorphism, a polymorphic function/method can be called with arguments of different types, and it may or may not denote a different behaviour in each case. In Java, this is achieved with method overloading.
One example is the java.lang.Math class, that has the following overloaded methods:
public static int abs(int a)public static long abs(long a)public static float abs(float a)public static double abs(double a)
Although the method is "the same" (aka, the name and number of arguments are the same), it receives and returns different types (if I pass an int, the return will be an int, if I pass a double, it'll return a double, etc). Of course, in a general case, the return type doesn't necessarily need to match the argument's type. The ideia is that a method can receive arguments of possibly different types, and return different things (and even the internal implementation can vary and perform distinct actions on each case).
Note that an overloaded method can also be called with a different number of arguments. Ex:
public int f(int x){
return x + 1;
}
public double f(int x, int y) {
return x + y; // no need to cast, int is automatically cast to double
}
If I call f(1), the result will be an int equals to 2, but if I call f(1, 2) the result will be a double equals to 3.0. And of course different languages will have different rules for defining that.
Note that this has nothing to do with inheritance. Both versions of f could be in the same class, and that'll work - that's how it works for Math class, as all the methods are in the same class (actually, they're all static, so they're not even related to an instance, which means that subclassing has no role at all in this kind of polymorphism).
Parametric
In parametric polymorphism, you can define a function/method or a type in a generic way, without depending on the underlying type. In Java, this is achieved by using generics, with the best known example being the collections classes.
Ex: the List interface is a generic datatype, and it's defined as List<E>, where E represents the generic type of the list elements. When using it, we can create a List<String> or a List<Animal>, and both will work, as the list was designed to work the same way, regardless of the elements' type (when I add or remove an element, or traverse through them in a loop, all works the same way, no matter what type E is).
Anyway, polymorphism can be achieved by using inheritance, but inheritance is not the only way to do it.
PS: I know that when someone asks about polymorphism and inheritance (and OOP), they usually want to know about the subtyping polymorphism, but I thought it was worth to at least mention that there are other types that don't need inheritance (or OOP).
OOP
Object oriented programming is a very broad topic and it's impossible to cover everything here. The other answer already scratched the surface, and I'd just like to add that there's not a single, unique, upon-agreed, free-of-controversies, canonical definition of Object Oriented Programming - although many agree with the "3 pillars" (encapsulation, inheritance and polymorphism - and some add "abstraction" as the fourth pillar). Anyway, each of these deserve their specific questions, IMO, as they're broad enough by themselves.
But instead of debating the definition, I believe you'd better just learn the concepts and when/how to apply them correctly. But if you want to really nitpick on this, why not start by reading what Alan Kay (the guy who "created" OOP - or at least the terminology) wrote about the topic (here and here)?
0 comment threads
1 comment thread