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 code?

Thank you.

Answer 1

very easy.

1. Abstraction is abstraction. Class 'Student' is an abstraction of a real student.

2. Polymorphism is when one class represents another so that user won't notice. This could happen when classes implement the same interface or one class derives from another. Class 'HighSchoolStudent' is derived from class 'Student'. When class 'Teacher' calls #attendance method on the object it might not know whether this object is of 'Student' class or 'HighSchoolStudent' class.

Answer 2

Abstraction

Imagine a fraction class:

class fraction:
    int denominator
    int numerator

Now two objects of that:

fraction(obj1): denominator=-1 numerator=-1
fraction(obj2): denominator=1  numerator=1

Both objects have the value 1: (1/1) == (-1)/(-1). You wouldn't expect they behave any different to the outside. That's abstraction. You abstract the data your object holds into a logical view, even tho behind the scenes, there are other things. Theoretically, you have got a equivalence relation, with different equivalence groups:

[1]=(1, 1), (-1, -1), (5, 5), ...
[2]=(2, 4), (-2, -4), ...
...

And there is a abstraction function that abstracts the internal details to the outside:

f((1, 1)) = [1]
f((-1, -1)) = [1]

It maps from concrete values to the abstract values of an object. You do that by writing for example a constructor mapping (-1, -1) to (1, 1) and by writing a equals function for your class.

Polymorphism

Imagine a pen and two derived classes:

class pen:
    void draw(int x, int y)

class pen_thin extends pen:
    void draw(int x, int y) { color(x, y) = green; }

class pen_thick extends pen:
    void draw(int x, int y) { color(x, y) = green; 
                              color(x, y+1) = green; }
and two objects:
    pen_thin(p1)
    pen_thick(p2)

Both pens can draw. your general "pen" cannot draw itself. It's just an interface to pen_thin, pen_thick and lots of other pens. You say: obj1.draw(1, 0); and whether obj1 is a thick or a thin pen doesn't matter to you as a user, neither to the compiler at compile time. The call behaves polymorphic. It's dynamic polymorphism (happens at runtime) and that's what people usually mean. Static Polymorphism happens at compile time:

class colorizer:
    void colorize(shirt s)
    void colorize(pants p)

That's called overloading. You call obj.colorize(something). If you call it with a shirt reference, it will call the version taking a shirt. And if you call it with a pant reference, it will call the pants version. The choice done here is at compile-time.

Answer 3

Abstraction refers to the act of representing essential features without including the background details or explanations. Classes use the concept of abstraction and are defined as a list of abstract attributes.

One example of a software abstraction is Java's Object.equals(Object o) method. You know that it will compare this object to the one passed in as a parameter, but you don't know, nor do you need to know, exactly how it will be implemented (unless you are the implementer of the class).

Polymorphism means the ability to take more than one form. A method might have different behaviors in different instances. The behavior depends on the data types used in the operation.

One of the classic examples of polymorphism uses an inheritance tree rooted in the Animal class. All Animal's have a makeNoise() method, but the Dog class and the Cat class implement it differently. This allows you to refer to any Dog's and Cat's using an Animal reference type.

Animal a = new Dog();
Animal b = new Cat();

Now you can call makeNoise() on either Animal instance and know that it will make the appropriate noise. This is particularly useful if you have a Collection of Animals, and you don't know at run time exactly what type each of them really is.

Answer 4

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 5

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 6

short answer: abstraction is conceptual, polymorphism is behavioral

Answer 7

These two are among the most important characteristics of Object Oriented paradigm.

Abstraction.

Object orientation models the software as real world objects. However it would be too hard ( and useless ) to model ALL the properties a Customer may have, or all the properties an Employee have.

By listing only the interesting attributes of an object OO may use effectively that object for an specific domain. That's abstraction.

For instance an Employee in a HR system may have very different attributes than a Online BookStore. We abstract the details to make is useful.

Polymorphism.

Objects may behave differently depending on the "type" while keeping the same interface.

What does this means?

For instance an online store system may have two sub-classes of Employee

A) Internal employees.

B) Contractors

And a method to calculate the discount for internal purchases

The discount of an internal employee is calculated as: 10% + 2% for each worked year in the company + 2% for each.. mmhh child

The discount of a contractor is simple 1%

The following code to calculate the amount to pay:

 public Amount getAmountToPay( Product product, Employee internalCustomer ) { 
      Amount amount = product.getPrice();
      amount.applyDiscount( internalCustomer.getDiscount() );
      return amount;
 }

Would produce different results for the two different kinds of Employee 's

class Employee { 
    public int getDiscount();
}


class InternalEmployee extends Employee { 
     public int getDiscount() { 
        return 10 + 2 * getWorkedYears() + 2 * getNumberOfChilds();
     }
 }

 class Contractor extends Employee { 
      public int getDiscount() { 
          return 10;
     }
 }

This is the polymorphism in action. Instead of having something like

 Amount amount = product.getPrice();

 if( employee.isContractor() ) { 
      amount.applyDiscount( 10 );
 } else if( employee.isSomthingElse() ) {
      amount.applyDiscount( 10 * 2 * getYrs() + 2 * getChilds() );
 } else if ( employee.contidions, condigions, conditions ) {
      amount.applyDiscount( getSomeStrageRuleHere() );
 }

We let the runtime to choose which one to calculate. Is like the program behaves differently depending on the type:

      Amount amount = product.getPrice();
      amount.applyDiscount( internalCustomer.getDiscount() );
      return amount;

By the way, in this example the "Amount" is an abstraction of a real life concept, that could also be represented as a double or an Integer, but maybe we have interestion methods inside that would be better if set in its own class.

I hope this helps.