Shulou(Shulou.com)06/02 Report--

Today, the editor will show you how to analyze the .NET interface, cats, dogs and programmers. The knowledge points in this article are introduced in great detail. Friends who feel helpful can browse the content of the article with the editor, hoping to help more friends who want to solve this problem to find the answer to the problem. Let's follow the editor to learn more about "how to analyze the .NET interface cat, dog and programmer".

The C# interface is something that makes many beginners of C# easy to confuse. It seems easy to use. It defines the interface and contains methods, but there is no code for the specific implementation of the methods. Then in the class that inherits the interface, you want to implement all the methods of the interface. But when you don't really realize the role of the interface, you feel that using the interface is superfluous. Of course, it is absolutely wrong to think so. Bill Gates' Microsoft employees are smarter than Gates, can their C # add so much?! With regard to the role of the interface, there is one on the Internet who has really made a good understanding analysis for us.

.net interface: cats and dogs

We define an interface

Public interface IBark {void Bark ();}

Define another class that inherits from IBark and must implement the Bark () method in it

Public class Dog:IBark {public Dog () {} public void Bark () {Consol.write ("woof");}}

Then, declare an instance of Dog and call the Bark () method

Dog Wangcai = new Dog (); Wangcai. Bark ()

Just imagine, if you want to call the Bark () method, you just need to declare such a method in Dog (). Why use the interface? Because there is no concrete implementation of Bark () in the interface. The real implementation is still in Dog (). So isn't it unnecessary to use interfaces?

Others put it this way: in terms of the definition of interface, interface is actually a kind of agreement and constraint between classes. Take the above example as an example. The Bark () method must be implemented in all classes that inherit the IBark interface. So from the user's point of view, if he knows that a class inherits from the IBark interface, he can call the Bark () method boldly, regardless of how the Bark () method is implemented. For example, we wrote another class.

Public class Cat:IBark {public Cat () {} public void Bark () {Consol.write ("Meow");}}

When users use the Cat class or the Dog class, knowing that they inherit from IBark, then regardless of the specific implementation in the class, you can directly call the Bark () method, because there must be a concrete implementation of the Bark () method in these two classes.

If we look at it from a design point of view. Several classes need to be written in a project, because these classes are more complex and have a large workload, so each class needs to be written by a staff member. For example, A programmer to order Dog class, B programmer to write Cat class. The two classes are not related, but because users need them to implement a method called. This requires a kind of restraint on them. Let them all inherit from the IBark interface, in order to facilitate unified management. The other is easy to call. Of course, the goal can be achieved without using the interface. Only in this case, this constraint is not so obvious, if there are Duck classes and so on, it is inevitable that some people will miss this method. So it is more reliable and binding through the interface.

.net interface: programmer

Through the study of the role of the interface in C# have a better understanding, take it out to share with you, there are wrong places to ask you to advise.

In my last post, I just briefly talked about the role of the interface, interested friends can take a look.

Back to the point:

Suppose there are two kinds of programmers in our company: VB programmers, programmers who write programs in VB, represented by the class clsVBProgramer, and Delphi programmers who write programs in Delphi, represented by the class clsDelphiProgramer. Each class has a WriteCode () method. The definition is as follows:

Class clsVBProgramer () {.... WriteCode () {/ / write code in VB language;}.... } class clsDelphiProgramer () {.... WriteCode () {/ / write code in Delphi;}.... }

Now the company has a project that requires a programmer to write a program.

Class clsProject () {.... WritePrograme (clsVBProgramer programer) / / write code {programer.WriteCode ();} WritePrograme (clsDelphiProgramer programer) / / overloaded method with VB, code {programer.WriteCode ();} with Delphi. }

In the main program, we can write:

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 in Delphi programer=new clsDelphiProgramer (); proj.WritePrograme (programer);}

But if there is another C # programmer in the company at this time, how can we change this program so that it can write programs in C #? We need to add a new class clsCSharpProgramer and overload the WritePrograme (clsCSharpProgramer programer) method again in this clsProject class. This is a lot of trouble. What if there are C programmers, C++ programmers and JAVA programmers? We're in big 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;}.... }

Make the following changes to the class clsProject:

Class clsProject () {.... WritePrograme (IProgramer programer) {programer.WriteCode (); / / write code}. } main () {clsProject proj=new clsProject; IProgramer programer; / / if you need to write code programer=new clsVBProgramer; proj.WritePrograme (programer) in VB; / / if you need to write code programer=new clsDelphiProgramer; proj.WritePrograme (programer) in Delphi;}

If there are more programmers like Java, we just need to add their related classes, and then make a slight modification in main () to OK. The expansibility is very good!

In addition, if we seal the clsProject class into a component, then when our users need to expand the function, we only need to make small external changes to achieve, it can be said that there is no need to change we have sealed the component! Is not very convenient, very powerful!

Thank you for your reading, the above is the whole content of "how to analyze the .NET interface cat, dog and programmer". Let's get started. I believe that the editor will certainly bring you better quality articles. Thank you for your support to the website!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.