Please see my comment to the question, which makes no sense. You did not show any polymorphism at all. We can talk about polymorphism only if we have some set of objects. Not just one object, a set. When a set can include object of some different types, we can talk about polymorphism. If course, if it is based on interface type, it is run-time polymorphism; how can it possibly be anything else?
I explained this kind of polymorphism in my past answers:
POLYMORPHISM WITHOUT OVERLOADING AND OVERRRIDING IS POSSIBLE[
^],
Interfaces and Polymorphism[
^],
Doubts on Interfaces[
^].
[EDIT]
girishmeena asked:
Hello SA, The only question i am trying to ask is "why we create variable of Type interface?" Suppose if we have 2 interface with same method, and a class implementing both interface. here we can create interface type and try to tell OK this method is related to Interface1.Foo() and this method is related to Interface2.Foo(). Is this the only scenario when we should create Interface Type?
This question makes apparent that you did not read some of my answers I just referenced.
First of all, you need to understand
runtime types vs
compile-time types. And also, more fundamentally,
types vs
instances. You create instances of types, not types. And you never create instances of interface types, and, likewise, not instances of any abstract types. (In this respect, interface types are always "abstract".) These types can only be the compile-time types, but the actual runtime types are always of some concrete types. This is the basis of polymorphism: from the compile-time standpoint, the type of the element of polymorphic set is some compile-time type, only one, and the runtime types are different. They are
assignment-compatible with the runtime type of the interface. When you do operations with the set, you never need to know the actual runtime types, because you access only the members common with the compile-time type of the set. The
runtime polymorphism is achieved throw either virtual methods/properties or implemented (possibly in different way, otherwise the mechanism not needed) interface methods/properties.
As to your "scenario", and the question "is this the only scenario", it all makes no sense. First of all, if a class implements two unrelated interfaces, "this method" cannot be the same. They would be different methods with the same name (just coincidence); then forget "the same" and consider they as two different methods. If two interfaces are related through inheritance, there are not two methods; this is the same method, so you can implement it only once. So, forget about "two methods"; this is totally unrelated to the use of interfaces.
Then again, you can talk about polymorphism only if you have a
set of instances, and different types; in case of interface-based polymorphism, different types implementing the same interface. All examples you discuss are about one instance. This is irrelevant.
By the way, you could find out in my past answers I referenced, that implementing more than one interface (those interfaces can be unrelated) is the feature which makes interface-based polymorphism more advanced then the interface based on a common non-interface (usually abstract) type. This is because not only classes, but also structures can implement interfaces, and because the same instance can participate in different types of polymorphic sets.
—SA