How does java achieve run time polymorphism?

Answer 1

Polymorphism is Greek for "many forms". There are two types of polymorphism: static and dynamic. Static polymorphism occurs at compile time and is also known as compile time polymorphism. Dynamic polymorphism occurs at runtime and is also known as runtime polymorphism.

Runtime polymorphism is a primary feature of the object-oriented programming paradigm. We achieve runtime polymorphic behaviour by defining virtual methods in a base class which derived classes can then override in order to provide more specialised implementations. Whenever we invoke one of these methods, the most-specialised override is executed automatically. In other words, polymorphic objects will behave according to their runtime type even when the runtime type cannot be determined at compile time.

Answer 2

In run time polymorphism compiler doesn't know about way of execution of program that mean decide way of execution at run time while in compile time polymorphism compiler know about the way of execution of program.

Example : compile time polymorphism -- method overloading

run time time polymorphism -- method overriding

Answer 3

Run time polymorphism maybe achieved by implementing a particular interface among different class hierarchies, or using the same delegate from different objects. (delegate maybe thought as an interface to invoke methods with different names but with the same parameters. These methods may or may not be of the same object/class)

Compile time polymorphism is achieved by classinheritance or implementing an interface.

Run time way means the actual implementing class is UNKNOWN (uncertain) at compile time, and maybe injected into your application in real time (through reflection is one way to get dynamic classes). Yet because the runtime object implements the predefined interface (at compile time), the "polymorphism" is achieved.

Answer 4

Whenever you declare or inherit a virtual function, you automatically create a virtual table for that class. The virtual table (or v-table) consists of one function pointer per virtual function, such that each pointer points to the most-derived override of the function. If a virtual function is not explicitly overridden by a class, the v-table entry points to the most-derived base class override instead. Whenever you instantiate any object within the hierarchy, its v-table will determine which specific override to invoke whenever a virtual method is called implicitly, regardless of where the call originates.

Consider the following example:

#include<iostream>

using namespace std;

struct A

{

virtual void foo() { cout << "calling A::foo()\n"; }

};

struct B: A

{

virtual void foo() { cout << "calling B::foo()\n"; }

};

void polymorphism(A& a)

{

a.foo();

}

int main()

{

A a; a.foo();

B b; b.foo();

poly(b);

}

Output:

calling A::foo()

calling B::foo()

calling B::foo();

In the above example, class A declares foo() to be virtual so class A effectively has a virtual table with a single pointer to A::foo(). B inherits from A and therefore has its own virtual table. B::foo() overrides A::foo(), so its virtual table entry points to B::foo(), the most-derived override. Had B not overridden this method, the entry would point to A::foo() instead, that being the most-derived base class override.

In the main function we instantiate an A object named 'a' and call the a.foo() method, thus invoking A::foo() as expected. We then instantiate a B object named 'b' and call b.foo(), invoking B::foo(), also as expected.

We than pass b into the polymorphism function. This is where runtime polymorphism comes into play. Note that the function expects a reference to an A object. Although the function knows absolutely nothing about B objects whatsoever, it invokes the B::foo() method when we pass a B object to it. This is entirely expected behaviour and shows runtime polymorphism at work. That is, the function did not need to switch on the runtime type of the object in order to invoke its more specialised behaviour.

The reason it works is because B inherits from A. Objects instantiated from B are really just more specialised instances of A, hence the compiler doesn't complain when we pass a B object into a function that expects a reference to an A object. Although the function doesn't know anything about B object specialisation, the v-table ensures it doesn't have to. The call is simply passed through the v-table pointer and since the object is really a B object, B::foo() is invoked rather than A::foo().

IMPORTANT! It should be noted that if you declare any virtual function, you must also declare the destructor virtual. This ensures that regardless of which object in the hierarchy falls from scope first, the most-derived destructor will always be invoked first, and the hierarchy will be destroyed in the reverse order it was constructed. Failure to declare the destructor virtual could result in leaked memory whenever a base class falls from scope or is explicitly deleted by code.

As a general rule, all destructors should be declared virtual even if there are no virtual methods in the class itself or in any of its base classes. The rule is only general because there will be some isolated cases where it would be undesirable for a class to be used as a base class, hence the default behaviour is non-virtual destruction. In some languages, all methods, including destructors, are declared virtual unless explicitly stated otherwise, but not C++. This is primarily to retain backward compatibility with the C-style struct where the virtual keyword would be meaningless.

Answer 5

we can achieve by the help of overloading and overrding cocepts and this two

methods are help ful in dynamic and static polymorphism.....