The role of the. NET interface
C # interface is a lot of beginners in C # is easy to confuse things, it seems very simple, define the interface, contains methods, but there is no way to implement the code, and then inherit the interface of the class to implement the interface of all the methods of code, but did not really realize the role of the interface is superfluous , of course, you think that is absolutely wrong, Bill Gates's Microsoft staff are Bugets also smart people, their C # can add such a lot?! On the role of the interface, online there is a really easy to understand to us to do a good understanding of the analysis.
We define an interface Public interface ibark { void bark ();} and then define a class that inherits from Ibark, and must implement the bark () method Public class dog:ibark { public dog () {} public void bark () { Consol.write ("barking"); } Then, declare an instance of Dog and call the Bark () method Dog wong Choy =new dog (); Wang Choi. Bark (); Just imagine, if you want to call the bark () method, only need to declare in the dog () such a method is not OK, what to do with the interface. Because there is no bark () implementation in the interface. Do you want to use an interface other than superfluous? Others say this: From the interface definition aspect, the interface is actually a kind of contract between class and class, a kind of constraint. Take the example above. All classes that inherit the Ibark interface must implement the bark () method. So from the perspective of the user (who uses the Class), If he knows that a class is inherited from the Ibark interface, then he can confidently call the bark () method without having to control how the bark () method is implemented. For example, we wrote another class. public class cat:ibark { public cat () &nbSp {} public void bark () { Consol.write ("Meow meow"); } When the user uses the Cat class or the dog class , knowing that they inherit from Ibark, then you can call the bark () method without having to do with the specific implementation in the class, because there must be a concrete implementation of the bark () method in these two classes.
If we look at it from the point of view of design. A project with several classes to write, because these classes are more complex, the workload is relatively large, so that each class needs to occupy a staff to write. For example, a programmer to the dog class, b programmer to write cat class. The two classes are not connected. But because users need them to implement a "call" method. It's going to be a constraint on them. Let them all inherit from the Ibark interface, the purpose is to facilitate unified management. The other is convenient to call. Of course, you can do this without the use of an interface. But that is not so obvious. If such a class has duck class, and so on, it is inevitable that some people will miss out on this method. So it is more reliable through the interface, stronger binding.
2.
the simplification of interfaces in C #
:
Through the study of the role of the interface in C # has a further understanding, take out to share with you, have said the wrong place please advise. I was in the Last Post (http://www.programfan.com/club/showbbs.asp?id=150228) just a simple talk about the role of the interface, interested friends can go to see. To get to the point: Suppose our company has two kinds of programmers: VB programmer, refers to use VB to write program programmer, use Clsvbprogramer this class to express; Delphi programmers refer to programmers who write programs with Delphi, Use the Clsdelphiprogramer class to represent it. Each class has a Writecode () method. Defined as follows:
Class Clsvbprogramer () {.... Writecode () {//write code in VB language;}
Class Clsdelphiprogramer () {.... Writecode () {//write code in Delphi language;}
Now the company has a project that requires a programmer to write a program. Class Clsproject () {.... Writeprograme (Clsvbprogramer programer)//VB Write code {programer. Writecode (); } writeprograme (Clsdelphiprogramer programer)//Overloaded method, with Delphi write code {Programer. Writecode (); } ...... } In the main program we can write this: main () {Clsproject proj=new clsproject ();
Iprogramer Programer;
If you need to write code in VB
Programer=new Clsvbprogramer ();
Proj. Writeprograme (Programer);
If you need to write code with Delphi
Programer = new Clsdelphiprogramer ();
Proj. Writeprograme (Programer);
}
But if the company came to a C # programmer, how do we change the program so that it can implement the function of writing programs in C #? We need to add a new class Clscsharpprogramer, and Clsproject this class again to reload the Writeprograme (Clscsharpprogramer programer) method. It's a lot of trouble. If there are C programmers, C + + programmers, Java programmers. It's too much trouble!
But if you switch to an interface, it's completely different: first, declare a programmer interface: interface Iprogramer () {Writecode ();} then declare two classes and implement the Iprogramer interface: Class Clsvbprogramer (): Iprogramer {.... Writecode () {//write code in VB language;}
Class Clsdelphiprogramer (): Iprogramer {.... Writecode () {//write code in Delphi language;} Make a change to the Clsproject class: Class Clsproject () {.... Writeprograme (Iprogramer programer) {programer. Writecode ();//Write Code} ...}
Main () {clsproject proj=new clsproject; Iprogramer Programer; If need to write code with VB Programer=new Clsvbprogramer; Proj. Writeprograme (Programer); If need to use Delphi write code programer=new Clsdelphiprogramer; Proj. Writeprograme (Programer); If any more programmers like C#,c,c++,java are added, we just need to add their related classes and then make a slight change in main (). Extensibility is particularly good!
In addition, if we clsproject this class into a component, then when our users need to expand the function, we only need to make a small external changes can be achieved, we can say there is no need to change the components we have sealed! is not very convenient, very powerful!
. NET Interface