Interface Type Variable

Question

1.00/5 (2 votes)

See more: (untagged)

I was just going through with the questions which was asked to me in recent interview. one question was

C#

interface ITest {}

public Class TestClass : ITest {}

class Program 
{
  static void Main(string[] args)
   { 
    ITest objtest = new TestClass();
   }
}

Whether it is run time or compile time Polymorphism?
I suppose answer is run time. Why? I don't know. phew :)

But why we even need to do like this ? i mean why we are creating a variable of Type interface.

Further, i write small code to understand this.

C#

interface Test
{
    void Add();
}
interface Test1
{
    void Add();
}
public class ChildI : Test,Test1
{
   public void Add() { Console.Write("Interface \n"); }
}
class Program
 {
  Static void Main(string[] args)
   {
    ChildI objtest = new ChildI();
    objtest.Add();  // "Interface"

    Test objtest1 = new ChildI();
    objtest1.Add() // "Interface" // How it is different from above ????
   }
 }

Thanks

Posted 9-Mar-14 9:12am

girishmeena

Add a Solution

Comments

Maciej Los 9-Mar-14 17:40pm

Not a question at all!

Sergey Alexandrovich Kryukov 10-Mar-14 0:41am

Why, this is a question, only not making much sense, with internal logical inconsistency...
I answered, please see.
—SA

girishmeena 9-Mar-14 23:23pm

Can you pls tell me why it is not a question ?

Sergey Alexandrovich Kryukov 10-Mar-14 0:20am

This is a question, but nearly nothing in it make any sense.
I'll explain. If you write some code which makes no sense, you cannot ask "why we need to do like this". No, it's not "we", it's you. Ask yourself.
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-03-09T18:40:00

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