Post History

> Disclaimer: 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](https://software.codidact.com/posts/282834#answer-282834), and adapting to Java code, as the questions used that language (and also assuming that each class is in its own .java file, as they're all `public`):

```java
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*).

<sup>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](https://docs.oracle.com/javase/tutorial/java/IandI/override.html) for more info.</sup>

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:

```java
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:

```java
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](https://en.wikipedia.org/wiki/Dynamic_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 ever further and make a method that receives a list of animals:

```java
// 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 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 using `instanceof`), 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:

```java
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](https://docs.oracle.com/javase/tutorial/java/generics/types.html), with the best known example being the [collections classes](https://docs.oracle.com/javase/8/docs/technotes/guides/collections/overview.html).

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 available way.

> 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](https://software.codidact.com/posts/282834#answer-282834) 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](http://wiki.c2.com/?NobodyAgreesOnWhatOoIs) - 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](https://www.quora.com/What-does-Alan-Kay-mean-when-he-said-OOP-to-me-means-only-messaging-local-retention-and-protection-and-hiding-of-state-process-and-extreme-late-binding-of-all-things-It-can-be-done-in-Smalltalk-and-in-LISP) and [here](https://www.quora.com/I-read-somewhere-that-object-oriented-programming-was-coined-by-Alan-Kay-circa-1966-or-1967-while-he-was-at-grad-school-Has-anyone-influenced-contributed-Alan-to-coin-such-a-term))?