How dynamic binding is useful in oops?

Answer 1

Dynamic binding makes it possible for objects to behave polymorphically even when we do not know the runtime type of the object.

Consider the following:

struct A {

int x;

int data() const { return x; }

};

struct B {

int y; int data() const { return y; }

};

Given that objects of type A and B are not of the same type, how can we pass just one instance of either type to the same function? One way would be to pass two separate references:

void foo (A& a, B& b) {

// ...

}

The problem with this is that we must have two objects to refer to whenever we call this function. If we only have one then we must instantiate a dummy argument for the other. That's hardly intuitive. And how would we differentiate the dummy from the actual argument? We could use pointers instead of references, passing nullptr for the unused argument, but that only serves to make it even less intuitive; a caller might easily pass nullptr for both arguments!

We could use function overloading and create two separate functions:

void foo (A& a) {

// ...

}

void foo (B& b) {

// ...

}

That's certainly more intuitive from the caller's point of view, but it's now a nightmare for the person who has to maintain this code in future. Every time we make a new class for this function we must define a completely new overload to handle it. The ideal here is to have just one function with one implementation.

We could use a void pointer.

void foo (void* p) {

// ...

}

That's certainly an improvement, but we still risk passing a nullptr. If we want to guard against this we must pass a reference, but we cannot declare a reference of unknown type. And the maintenance nightmare still exists because we still have to determine the actual runtime type before we can dereference the pointer.

Let's look at those type definitions again.

struct A {

int x;

int data() const { return x; }

};

struct B {

int y;

int data() const { return y; }

};

Although they are completely different types, they both have a common method, data(). We can exploit that fact by percolating this "pure" interface into a common base class:

struct Base {

virtual int data() const = 0;

virtual ~Base() {}

};

struct A : Base {

int x;

int data() const override { return x; }

};

struct B : Base {

int y;

int data() const override { return y; }

};

Now we can define our function in terms of this one common, abstract base class:

void foo (Base& base) {

int z = base.data();

// ...

}

Problem solved! Now we can derive as many different classes as we want from Base and the foo() function will work as expected without any changes. Note that the function makes no reference whatsoever to the actual runtime type. This is because it doesn't need to know the runtime type, it only needs to know the interface defined in the one and only class that it does need to know about, the Base class!

Note that since the Base class has no data, there is no memory overhead:

assert (sizeof(A)==sizeof(B)==sizeof(int));

The only real overhead is in the virtual tables which is where dynamic binding comes in. When we invoke the Base::data() virtual method, that method is dynamically bound to either A::data() or B::data(), depending on which specific class we passed to the foo() function.

Note also that when we declare a virtual method, we must also declare the destructor virtual as well. This ensures that the most-derived class is always destroyed first, even if we only hold a pointer to its base class:

Base* p = new A {42};

// ...

delete p; // OK -- A is destroyed before Base due to virtual destructor.

Again, virtual destruction is an example of dynamic binding.

Answer 2

• User-modelling and interface customization. Applications I develop tend to be targeted to very specific audiences. I sometimes provide an initial survey or dialog box that lets the user customize the interface. I've been able to develop a suite of interface components that are easy to customize at run-time by switching their ancestors. If, for example, the user is a Spanish-speaking women who is a computer expert, the application can change the ancestor of on-screen text objects to the Spanish Language ancestor and change the ancestors of other interface objects to the Expert ancestor. If at some time in the presentation the user would like more help, the application can switch ancestors to Normal mode, and then switch back to Expert mode later.
• Preservation of object properties. Object properties persist across changes in mode, movies, etc. I've found this feature very useful for returning to a stable state after a user-initiated digression.
• Extensibility. The boss says we need a French language version by 5 pm. No problem. I've already isolated language specific behavior in a Spanish Language ancestor. I copy it, change the Spanish to French, add a line of code to switch the ancestors to the French version and voila!

Of course, all this can be done with globals and nested if-then statements too. I've found this approach easier to maintain and much, much easier to extend and customize.

Answer 3

Both possible.

In Java static binding is binding at compile time while dynamic binding is binding at runtime.