Click here to Skip to main content
15,064,915 members
Please Sign up or sign in to vote.
2.50/5 (2 votes)
See more:
I have got a one question about interfaces.

Everyone knows that polymorphism is
creating object as base class from deriveted class which will be execute at runtime with late binding.

But I dont understand How do Interfaces do it like a base class ?
I asked is interface is a class ? or Interfaces references how can set other object references which class implement interface. I look the MSIL code with Reflector but I cant find anything which I m looking for.

Have someone with the idea of this.
Good works everyone
Sergey Alexandrovich Kryukov 15-Jan-12 22:33pm
Most of the question is pointless. The only reasonable part would be: "can I use interfaces for polymorphism, similar to abstract classes?" The answer is simply "yes".
Sergey Alexandrovich Kryukov 15-Jan-12 23:32pm
Nevertheless, after looking at all posts I voted 4, which rarely happens.

alikaras wrote:
creating object as base class from deriveted class which will be execute at runtime with late binding
As you may easily note, this mechanism (polymorphism) only needs method signatures of the base classes (not else). Hence interfaces ('contracts' because they just provide such methods signatures) are perfectly valid for substituting base classes in the polymorphism mechanism.
alikaras 15-Jan-12 17:50pm
Thanks for solution;
but I dont understand clearly,
Is it possible to explain with an example of a wider
Sergey Alexandrovich Kryukov 15-Jan-12 23:21pm
Good point. OP is still not getting it, but we are probably don't understand what seems to be not clear.

I voted 5 by I can see a lot more to it. Please see my answer as well.
Your definition of polymorphism is wrong. You just tried to explain what is "late binding" using the term "late binding'. It makes no sense.

The polymorphism comes into play when and only when you have a set of objects; and a each object is represented by some parent compile-time type which can be abstract or pseudo-abstract. The run-time types of the objects of the set are different. If the common base type is abstract, they are never of this type, apparently.

Now, this base class representing all object in the set can either be a class or interface. Historically, interfaces appeared later then abstract classes to represent pure entities. Originally, interfaces were modeled based on the "pure abstract" class, that is, the class which has no members except abstract methods. Later on, people separated such classes from interfaces in syntactic way. Also, interfaces can use multiple inheritance, and the class using interfaces can use the weak form of multiple inheritance, that is, only one class can be a base, but also unlimited number of interfaces. By its mechanism, the functioning of interfaces is very similar to that of "pure abstract classes" described above.

You should not think of interfaces as something not existing during run-time. An interface is a reference to some part of virtual message table. Think what happens if you have a class and cast it in two different (due to multiple inheritance) interfaces. You obtain two physically different references, because one interface is unaware of another one. Think about it.

Now, polymorphism with interfaces is more powerful then that with base classes. First, with multiple inheritance, the same object can participate in more than one polymorphous set of different base types (interfaces, in such cases). What's more, you can implement an interface not only in class, but also in a structure. But structure is a value type and cannot even have virtual methods! Can you see how deep this is? You can work in a way agnostic not just to a concrete run-time type, but also be abstracted from the knowledge of what kind of type is the member of a set: a reference type (a class, which can use virtual method) or a value type (a structure, no virtual method mechanism).

alikaras 16-Jan-12 2:42am
Thanks a lot SAKryukov
You understand that what I'm want
this is a good explanation and good solution I think you can write a article abaout this on the another title if you want.
Thanks to all of who
You are welcome.
As to the articles, I've already written a few, you can find some on CodeProject, thank you for attention. :-)

Good luck, call again.
CPallini 16-Jan-12 3:27am
My 5.
Thank you very much.
thatraja 16-Jan-12 5:36am
Sergey Alexandrovich Kryukov 16-Jan-12 12:32pm
Thank you, Raja.
An interface is not a class. You can think of an interface as a contract that specifies the behavior of a class.
alikaras 15-Jan-12 15:09pm
this is not answer for my question.I know what were you write.

I read lots of article for this but I cant find the correct dot for my problem.

[no name] 15-Jan-12 15:24pm
Then perhaps you should ask a better question. "I asked is interface is a class?"
Which I replied to to.

Edit your question and rephrase to make it more clear what information you are seeking.
alikaras 15-Jan-12 15:36pm
My english not very well :)
class BaseClass
class DerivetedClass:BaseClass
BaseClass sample = new DerivetedClass();

I Understand this BaseClass is a Class

BaseClass sample = new DerivetedClass() --> like a boxing because BaseClass is a main class

interface IBase
class DerivetedClass:IBase
IBase sample = new DerivetedClass();

What is the differences between

BaseClass sample = new DerivetedClass()


IBase sample = new DerivetedClass();

is interface a class in background this is my question so I look the MSIL code with reflector but I cant find what Im looking for.

Im waiting professional answer this problem.
[no name] 15-Jan-12 16:09pm
Once again, no, an interface is not a class. You can't instantiate an interface, similar to an abstract class. However, whereas an abstract class may have implementation an interface has no implementation; only the signatures that must be implemented in a class. An interface can be used to reference classes of different types that may not have any base class. For instance, when making a generic data access library you could have methods that take IDbCommand. This way you could have classes that support SQL Server, Oracle, MySql, and others, and as long as they implement IDbCommand, they are all interchangable. The method doesn't have to cast the parameter to the proper class, just call the desired method because the class is guaranteed to support it.

You may want to read this
Andreas Gieriet 15-Jan-12 16:12pm
An interface is an interface. A class is a class. You will see that in the MSIL too. So, what "professional" answer do you expect?
Sergey Alexandrovich Kryukov 15-Jan-12 22:36pm
You need to understand only one thing, and then you will understand the rest. Who told you the questions like "what is the difference between {0} and {1}?" are correct. They are not, they make no sense.
Andreas Gieriet 15-Jan-12 16:14pm
My 5 for your concise answer - and your patience ;-)
alikaras 15-Jan-12 16:19pm
I was amazed to Interface is carriying the object reference with late binding.
how it do this I wonder. I havent read about this before, there are only interfaces can support polymorphisim but how ?
Andreas Gieriet 15-Jan-12 16:27pm
Your statement confuses me (i.e. I would say it's wrong).
Polymorphism is given for IBase obj1 = ... as well as for BaseClass obj2 = .... Or do I miss something in your statement?
Andreas Gieriet 15-Jan-12 17:00pm
I think the key of the confusion lies in the way you describe polymorphism in your original question.
Polymorphism means "it can take various forms". Translated into C#: a variable of a certain type (e.g. IBase obj1 or BaseClass obj2 can hold concrete objects of variing forms. The means that C# provides such that one can use polymorphic variables is: classes derived from classes and classes implementing interfaces.
alikaras 15-Jan-12 16:25pm
No one had to write back, but at the same time I'm free to think.
and still do not have to treated as a fool,
told them to do better google translator in the translation, but I think I have a question to be answered in the middle. for your patience hoh :)
BillWoodruff 15-Jan-12 23:04pm
No one has treated you like a "fool" here ! Talented people with years of techncial experience and deep theoretical understanding of computer science have been replying patiently to your confusion.

If you do not see that, then you are "acting foolish," but that is a behavior, not something you "are."
Sergey Alexandrovich Kryukov 15-Jan-12 23:33pm
I actually appreciate OP's attitude, otherwise I wouldn't waste so much time for my answer; and I voted 4 for the question.
Sergey Alexandrovich Kryukov 15-Jan-12 23:26pm
I actually appreciate your interest and an attempts to get to the very essence of things, otherwise I wouldn't waste so much time for my answer. You just need to be more accurate in logic and formulations, but this is a requirement for all of us.
it is easy sample which I wrote it before.

My purpose is not wrangle with you
Isnt it a polymorphisim ?
    interface IBase
        void write();
    class Sample1 : IBase
        public void write()
            System.Windows.Forms.MessageBox.Show("Im Sample1");
    class Sample2 : IBase
        public void write()
            System.Windows.Forms.MessageBox.Show("Im Sample2");
    class sample
       public void Sample()
            List<IBase> myList = new List<Ibase>();
            myList.Add(new Sample1());
            myList.Add(new Sample2());
            foreach (IBase item in myList)
[no name] 15-Jan-12 18:15pm
Interfaces themselves are not polymorphic. You can not derive one interface from another. Polymorphism is applied to the CLASS that IMPLEMENTS the interface. Each implementation of the interface can be different.

A solution should not have been added. You should have edited your question to provide more detail or rephrase the question.
Sergey Alexandrovich Kryukov 15-Jan-12 23:23pm
Yes, this is polymorphism, but neither interfaces not base classes are polymorphous by themselves.
Please see my answer.

Also, please remove this post and move it content to the question using "Improve question" above. This is not a solution.

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

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900