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

Abstraction and polymorphism are critical concepts by no means limited to OO. Adding to the confusion, the word 'abstraction' is used multiple ways. Here is a quick cheat sheet with one example:

• Data abstraction means information hiding. Usually what is hidden is the representation of a data structure. Example: I implement sets, but I don't tell you whether a set is represented as a list, a balanced binary tree, or an unbalanced binary tree. Done right, I can change representation without breaking your code.

• Polymorphism means reuse with different types. So with my set example you could create sets of Social Security numbers, sets of full names, or sets of fruitbats, all using the same code.

Obviously you can define a class which is both abstract and polymorphic.

Polymorphism is further confusing because there are two ways to implement polymorphism. In parametric polymorphism, you can reuse the set with values of any type, or maybe any type satisfying some constraint. The most obvious examples are C++ templates; if you write

class Set <T> { ... }

Then T is the type of objects contained in the set (the notation <T> indicates a so-called "type parameter", which is what makes it parametric polymorphism).

In subtype polymorphism, you can reuse sets only with objects whose types are subtypes of a particular type. For example, you might be able to make sets only of objects that offer a less-than-or-equal-to method. In a true object-oriented language like Smalltalk or Ruby, which offer so-called duck typing (us pointy-headed theorists sometimes call it behavioral subtyping), the presence of the method is good enough. In a language like Java or C++, which conflate subtyping with inheritance, your use of polymorphism may be restricted to subclasses of a particular class. (Java further confuses the issue by using one form of subtyping on classes and another on interfaces.)

Finally, old farts like me talk about procedural abstraction, which just means being able to take a bunch of statements that are frequently used together and plop them into a procedure or method which you can then reuse. It's probably not germane to your question.

So, do you feel better about being confused?

Answer 2

short answer: abstraction is conceptual, polymorphism is behavioral

Answer 3

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.

Answer 4

Both terms are used heavily in object oriented programming, but they are not specifically limited to that context.

Abstraction is a generalization of something else; a step higher in perspective. A heirarchy for instance can be seen as an abstraction on the organizational structure of a company. Generally it is used in the context of what things are underneath (such as their base types). The point of abstracting is to write less code that is more general in nature, so that you can run it for a larger set of problems. A spreadsheet for example is an abstraction that allows for a specific type of information storage. More?

Polymorphism is also a generalization, but one that occurs in a runtime context. A bunch of different object types are polymorphic if there is some way to access them where they are indistinguishable from each other. That is, all of the objects look and feel the same, even if they are not. The purpose of this is to significantly reduce code; you can write one generalized solution to save from writing all of the different permutations for each different type. If you write a graphics library, you'd rather just write some abstract code to handle 'shapes', then have to write code for each different type, such as circles, squares, etc.

These are both terms that are centered around properties in the code that will enable the programmers to do more with less. Less code has less bugs, is more stable and is easier to maintain. The alternative is to use "brute force" to pound out millions and million of lines of very specific (and very fragile) code. More code is harder to fix, and much harder to keep up-to-date.

Paul.

Answer 5

In simple term, Abstraction is conceptual and Poly is behavioral. In order to achieve abstraction in OOP, you need Poly.

Abstraction in object oriented programming is a concept or design pattern I may say, which enables better isolation, loosely coupling thus testability, and reusability and extensibility. In order to achieve all, we need poly, inheritance/extension and etc.

Answer 6

P.S: recently started learning java answer is based on my observation please correct me if i am wrong.

Abstraction and Polymorphism basically deep down does almost same work in programming .

let's Take a car for example..

it doesn't matter whether it is a Ford mini-van, Ferrari exotic, Land-Rover SUV or a BMW sedan they all follow a basic design of a car i.e an engine, a steering wheel , a gear box , lights , indicators and list goes on . what makes them different is their specific implementations like Ferrari might have a more powerful engine than a mini van, a suv might have a different gear box hence A car (Superclass over here) has been implemented by subclasses (sedan, suv , mini-van, exotic) This is polymorphism, a basic idea being inherited or implemented by adding other specification. a 4 wheel vehicle (superclass) being implemented in various forms (subclasses)

Now, Abstraction , by definition it means hiding the details and making user see what is required by him..

Let's take example of car again.. You use gear but you don't know exactly the mechanism of how exactly the gear works and changes speed and all..

Now over to coding Part.

Abstract classes are incomplete classes and for a class to be abstract as the name suggest they need to have an incomplete method that needs to be completed by the subclass inheriting the superclass , IF they don't complete the abstract method they will stay incomplete as well.

abstract class car {
  abstract void gear();
}

class sedan extends car {
 public void gear()
 {
  //complete the method
 }
}

also you can not create objects of abstract classes because class is not complete. Yet these abstract classes can have static methods , arguments , concrete methods BUT for them to be abstract they need one abstract method. So one basic abstract superclass is implemented in other subclasses where they complete it By looking at the method declaration we can estimate what exactly the method is doing, what it is going to return. But we don't know how exactly the abstract method will be implemented.

By using abstract classes or interfaces , we can achieve abstraction in Java. As we all know that abstract classes, interfaces contains abstract methods

We can only estimate how they will work . We get to know how they work, once we provided the method implementation in the classes which implement the corresponding abstract class or interface.

HENCE, abstract basically helps polymorphism.