Simple introduction-Understanding Program Interfaces

When I was in the charging system of the IDC room, I had access to interfaces and often heard from the master, but I didn't really check the information and learn it. When I learned the UML video this time, I came into contact with the interface. This time I had to learn about it and found the interface history interesting and interesting.

Program interfaces are one of the two types of interfaces provided by the operating system for users. Programmers request the operating system to provide services through program interfaces.

　
To introduce the interface, you must introduce the history of the development of the program language. Mr. Lu Xun said that "The History of the first governance of the study" and understood the past and present of the development of the program language, only then can we know why so many languages are like this and why is that?

　　

First, we will introduce a concept: "Granularity ",What is granularity? The so-called granularity is the combined scale of code units used in a program. We can give an example:

Gravel ?? Bricks ?? The house template, we imagine building a house, there are actually many ways to build, if you don't have trouble, you can use gravel a little bit of building, or burn gravel into bricks, bricks are used for building, and even doors, windows, and wall components of houses are directly purchased from the factory. These three different methods represent three different combination scales. Gravel is the smallest unit. It may be enough to build a small house, but there is no doubt that we must use a lot of "gravel", which is not easy to manage. Bricks aggregate a layer than gravel, it can be used to build a large house. The Housing template is of the highest size and can be used to quickly build a large-scale house. The differences and connections between these three scales are very similar to the programming concepts.

The teacher told us that the most basic units for this process-oriented language are processes and functions, which are the smallest components in the program. Processes and functions can achieve the most basic code reuse. When we write code using some fixed functions and functions, we can call them in a program without having to write such a piece of code wherever necessary, which is obvious. In some small programs, the use of procedures and functions is appropriate, but in large and medium-sized programs, their drawbacks show that the granularity of processes and functions is too low, if one of our systems has 10000 functions and processes, our programmers will have to spend a lot of time searching for and maintaining them, the difficulty of managing 10000 unrelated functions and processes is obvious, just like that of 10000 enterprises. If there are no departments or positions, isn't this messy ?!

The emergence of object-oriented language is to solve this problem. Don't listen to the chaos of OO language. In fact, it is a reason: to improve the programming granularity. The basic unit of object-oriented language is class, which encapsulates many data members and member functions. The process increases the minimum component level, what we need to directly operate is not the process and function, but the classes at a higher level. We have divided 10000 people into many departments, and different departments are responsible for different matters, so that the company can finally get on the right track.

Is it all right if I have made a class? Not necessarily, new problems may follow. Maybe we have many people in one department and can do many things. How can we achieve better management within the Department? For example, we have a class that provides many methods and attributes. These methods and attributes can be divided into a bunch of functions to serve different functions. However, our class does not manage these methods. In AO, map objects have many functions, such as Layer Management, element management, selection set management, and map display. Each function has many methods and attributes, these attributes and methods are disorganized, and there is no difference between them in a class. When our programmers need to find a method, they have to look for it one by one, which is inconvenient.

At this time,Interface appearsWhen C ++'s inventor first proposed the concept of pure virtual functions (actually interfaces), he suffered a lot of resistance. Many people do not understand the meaning of interfaces, we use virtual functions. Why is there an empty shelf for nothing? It is a class, and it cannot produce an object; it is an object, and there is no method body to use. A good thing is to classify the class. For map objects, we can perform several interfaces that define methods, functions, attributes, and map interfaces of different functions to implement these interfaces. In this way, we can use interface definitions to implement objects. Therefore, the so-called interface is the definition of a series of related methods and attribute sets.

　　

Dim pGraphicsContainer as iGraphicsContainer 　　pGraphicsContainer=application.document.ActiveView.focusMap 

Pgraphicscontainer can only use the attributes and methods defined by pgraphicscontainer, but cannot use the methods and properties defined by interfaces such as management elements. How can we use other functions? This is the so-called Qi (query interface) function. Query another interface from one interface.

　

　Dim pGeoFeatureLayer as iGeofeatureLayer 　　pGeoFeatureLayer= pGraphicsContainer QI 

Well, after talking so much, we have already entered the concept of COM. Before the official introduction of COM, we have to come to the last point: the development history of computer language, in fact, it is a history that constantly improves the granularity of components and constantly improves the history of code reuse. Previously we used procedures and functions, and then we used classes. Now weInterfaceFor the same purpose, let us find a balance between the specific and abstract components we operate on. Too specific, such as procedures and functions, there will be no framework; too abstract, such as classes, there will be no separate.

Sample Code:

　　

public interface IForm 　　{ 　　void Show(); 　　void ShowDialog(); 　　} 　　public class A:IForm 　　{ 　　public void Show() 　　{ 　　} 　　public void ShowDialog() 　　{ 　　} 　　} 　　public class B:IForm 　　{ 　　public void Show() 　　{ 　　} 　　public void ShowDialog() 　　{ 　　} 　　} 　　public class FormFactory 　　{ 　　public static IForm CreateInstance(string parm) 　　{ 　　if (parm == "A") 　　{ 　　return new A(); 　　else if (parm == "B") 　　return new B(); 　　} 　　return null; 　　} 　　}