What is the difference between Abstraction and Polymorphism

Question

I seem to not understand two OOP concepts very well. Could you explain what abstraction and polymorphism are, preferably with real examples and

Answer 1

The confusion regarding the actual meaning of abstraction in the context of object orientation is comprehensible: it adds little, if something, to the concepts of inheritance, encapsulation and even polymorphism. If you master these three concepts, there is no need to concern too much with "abstraction" once it is naturally embedded in them (particularly inheritance).

To start with, note that the term "abstraction" has multiple meanings and it is not incorrect to state, e.g., that encapsulation requires abstraction: when you use access modifiers to protect the attributes of a class while exposing the methods that handle them (that's what encapsulation is), the class' user no longer needs to worry how to handle them by herself. So, in a sense, when you design a class, you abstract by properly encapsulating methods and attributes - everything the class' user needs to do is use it by invoking the right methods, and this is a form of abstraction.

Furthermore, if you think straight, polymorphism is also a form of abstraction: your code calls a method provided by some class and you have no idea how it is gonna act until that actual class type is determined (at runtime). So, it is correct to state that the polymorphic behavior is a kind of abstraction.

However, when used as a standalone term to describe the characteristics of OOP, abstraction must be understood as the proper representation of the system under discussion in the form of a suitable class hierarchy. As such, abstraction is the result of the designer's mental processes that culminate in an appropriate design for the classes that are gonna be used in a program. To quote an (excellent!) post that can be found at the javarevisited blog:

... Abstraction hides details at the design level, while Encapsulation hides details at the implementation level.

While the above statement is correct, I find the "hides details" part misstated - I would rephrase it as something like

Abstraction concerns with design details, deciding how the class hierarchy should look like, Encapsulation hides details implementation.

To be fair with the author, this very idea is put beautifully along his article. The term "abstraction" with this connotation is also seen in good books like Head First Object-Oriented Analysis and Design, and I quote a statement from there:

Whenever you find common behavior in two or more places, look to abstract that behavior into a class, and then reuse that behavior in the common classes

Notice the usage of abstraction here: "look to abstract that behavior into a class". Now, if to abstract means to design a class hierarchy properly as suggested above, abstraction could be defined as the representation of a domain by using classes conveniently, taking advantage of the concepts of inheritance and encapsulation.

In the particular case of Java, abstraction is implemented by using interfaces and abstract classes while encapsulation is implemented with the private, protected and package access modifiers.