A little further down in that discussion John Burton makes a comment[^] about them which makes me think they are used to describe a virtual function as we do in C++. However with your[^] comment they appear to implement the flavor of inheritance to a class. Both of which make some sense, however I would really like to read a full article where they are described in great detail. Thanks for the link though.
The goal of Computer Science is to build something that will last at least until we've finished building it. - Unknown
The problem is that C# is new enough that it is all a matter of opinion. To offer a single article (which I don't have, or I would do anyway) would be to offer only one person's opinion.
To my mind, neither viewpoint that you've picked out is strictly wrong, nor are they mutually exclusive. An interface is sort of like an abstract class for a language that otherwise doesn't allow multiple inheritance. So in a way, it is like offering a set of virtual functions.
The most useful purpose of this is to offer a flavour of inheritance to the class.
I do think it could be better though . What an interfaces article needs is a single practical example: this is an interface, these are two classes that might implement this interface. What this does is say: this is an interface, and this is how you use one that already exists, proving how difficult it is to find a practical use for interfaces (the StringList example is pointless).
Just thinking aloud. I might be tempted to work on this when my workload calms down over the next few weeks and I get to finish the one I'm already working on.
Paul Riley wrote: By the way, can I ask [slightly off topic] - why did you choose to use get... methods, rather than read only properties?
Now for then even MORE off topic answer.
If a property has a ReadOnlyAttribute, the property will only be readonly to the designer, but it is still settable programatically, where only defining only a get property is never settable (pretty obvious)
Give them a chance! Do it for the kittens, dear God, the kittens!
As seen on MS File Transfer: Please enter an integer between 1 and 2.
I pocket a class in a dll.And the class implement a interface.
and then I load the dll with these code:
Assembly a = Assembly.Load("mydll");
Type t = a.GetType("mydll.myClass");
object obj = Activator.CreateInstance(t);
MyInterface Imyclass=(MyInterface)obj;//this line will cause runtime error;
The biggest problem is that when I use it as below,it can work.
import the dll to my project first.
MyInterface Imyclass=new myClass();
Are you fun me???Interface can not be create a instance.
Type t = t2.GetInterface("MyInterface");
MyInterface obj = (MyInterface) Activator.CreateInstance(t);
Absolutely these codes will make a exception;
Can you make a test before makeing your answer?
Is the interface compiled along with the assembly that you load? Interfaces have assembly identity, so both the assembly you'll load and the loader need to reference the interface in the same assembly.
There can also be version number issues. If the interface gets recompiled after you've built mydll, the versions won't match.
Thank you first,but the problem is still here.
I think it doesn't matter with the version.
I made a test like this.
First I build a interface(Imyclass) in a Imyclass.dll;
Reference it in the project of myclass which implemented the Imyclass and build a myclass.dll
And then,reference the Imyclass.dll to the project want to load myclass.dll at runtime.
and these codes will still create a exception(specified cast is not void);
Imyclass ImyCls =(Imyclass)Activator.CreateInstance(t);
In this case,the version of Imyclass.dll will same in each project,and the problem is still going on.
Some thing special is ,in myclass,I used some struct defined by myself for fuction parameters and return value.Is that the problem of system defult serialization???
lost my way
Last Visit: 31-Dec-99 18:00 Last Update: 1-Oct-23 22:11