Program interface

The program interface is a service invocation mechanism provided by the operating system for programmers. It enables the interaction between user programs and the kernel through system calls, covering functions such as process control, file operations, and process communication. As the sole legal entry point for applications to access system resources, it triggers the switch from user mode to kernel mode through software interrupts, uses registers or parameter tables to pass requests, and is ultimately executed by the kernel and returns the result.
The development of program interfaces has evolved along with the evolution of programming paradigms. In the early stage, procedural languages used functions as the smallest unit, while object-oriented languages introduced class to encapsulate data and methods. To solve the problem of mixed functions within classes, the interface mechanism defined modular method collections through pure virtual functions. C++ was the first to implement the interface query (QI) technology to switch functional modules. System calls, as the underlying implementation of interfaces, gradually standardized to specifications such as POSIX and enhanced usability through API encapsulation.
Interface Introduction Announcement
Editor
When introducing the interfaces, it is necessary to first introduce the history of the development of programming languages. Lu Xun once said, “Studying requires understanding history first.” Only by understanding the past and present of the development of programming languages can one understand why so many languages are like this and how they are like that?
After the emergence of computers, scientists successively developed various languages, such as Smalltalk, Pascal, Basic, C language, C++, Java, .NET, etc. The development pace of these languages can be regarded as a period of history from procedural programming to object-oriented programming. Many books on object-oriented programming, when introducing their own history, will introduce this period of history to readers and promote OO (Object Oriented) programming as being extremely excellent. The problem is that many people who are just starting to learn programming have no idea why there is this transformation. They also have great difficulty understanding the concepts such as virtual functions and interfaces in OO languages, and why they were introduced.
Granularity Announcement
Editor
Before we delve into this historical period, let me introduce a concept to you first: “granularity”. What is granularity? The author believes that granularity actually refers to the scale at which code units are combined within a program. Let’s take an example: gravel?? bricks?? house template. Suppose we want to build a house. There are many ways to do it. If you don’t mind the effort, you can build it with gravel one piece at a time, or heat the gravel into bricks and use them to build with, or directly purchase door, window, and wall components from the factory to stack them. These three different methods represent three different combination scales. Gravel is the smallest unit. Using it to build a small house might be okay, but undoubtedly, we must use a lot of “gravel”, which is not easy to manage; bricks are one layer more aggregated than gravel and can be used to build larger houses; the house template is the highest size and can be used to quickly build large-scale houses. The differences and connections between these three scales are very similar to the concept of writing programs.
When learning Pascal in the early days, the teacher told us that the most basic unit of this procedural language is procedures and functions, which are the smallest components in the program. Procedures and functions can achieve the most basic code reuse. When we write certain fixed-function code using procedures and functions, we can call them in the program without having to write such a piece of code in every place where it is needed. The benefits are obvious. In some small programs, using procedures and functions is appropriate, but in medium-sized and large programs, their drawbacks become apparent. The granularity of procedures and functions is too low. If we have a system with 10,000 functions and procedures, our programmers will have to spend a lot of time finding and maintaining them. The management difficulty of 10,000 unrelated functions and procedures is obvious; it’s like 10,000-person enterprises without departments and positions, wouldn’t it be chaotic?
Object-oriented Announcement
Editor
The emergence of object-oriented languages was precisely to address this issue. Don’t listen to the exaggerated claims made by OO languages. In fact, their existence was for a single reason: to enhance the granularity of programming. Object-oriented languages have a basic unit called CLASS. This class encapsulates many data members and member functions, procedures, elevating the granularity of the smallest component by one level. What we need to directly operate on is no longer procedures and functions, but individual higher-level classes. We divided 10,000 people into many departments, and different departments were responsible for different matters. Thus, the company finally got on the right track.
Did making the CLASS class solve everything? Not necessarily. New problems emerged. Perhaps we have a department with many people 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 actually be divided into many groups to serve different functions. However, our class did not perform this management. In AO, the map object has many functions, such as managing layers, managing elements, managing selection sets, and performing map display. Each different function has many methods and attributes, which are scattered and unorganized within a single class. When our programmers need to find a method, they have to search one by one, which is very inconvenient.
At this time, the interface interface emerged. When the inventor of C++ first proposed the concept of pure virtual functions (which is actually an interface), it was met with much resistance. Many people did not understand the significance of interfaces. We use virtual functions well, why come up with something that has no functionality and is just an empty framework? Saying it is a class, it cannot produce an object; saying it is an object, there is no method body to use. The interface emerged to do a good job, that is, to categorize the internal structure of the class. For the map object, we can create several interfaces. These interfaces define different functions’ methods, functions, and attributes. The map class implements these interfaces, allowing us to use interface definitions to implement objects. Therefore, an interface is the definition of a set of related methods and attributes. Dim pGraphicsContainer as iGraphicsContainer
pGraphicsContainer=application.document.ActiveView.focusMap
The attributes and methods that pGraphicsContainer can use are only those defined by itself, and it cannot use the methods and attributes defined by interfaces such as managing elements. So how do we use other functions? This is what is called the QI (Query Interface) function. Querying one interface from another. Dim pGeoFeatureLayer as iGeofeatureLayer
pGeoFeatureLayer= pGraphicsContainer QI
The development history of computer languages is actually a history of continuously increasing the granularity of components and the degree of code reusability. Previously, we used procedures and functions, then we used classes, and we used interfaces, all for the purpose of finding a balance between specificity and abstraction when operating components. If it is too specific, such as procedures and functions, there would be no framework; if it is too abstract, such as classes, it would be impossible to differentiate.
A code example: publicinterfaceIForm
{
voidShow();
voidShowDialog();
}
publicclassA:IForm
{
publicvoidShow()
{
}
publicvoidShowDialog()
{
}
}
publicclassB:IForm
{
publicvoidShow()
{
}
publicvoidShowDialog()
{
}
}
publicclassFormFactory
{
publicstaticIFormCreateInstance(stringparm)
{
if(parm==”A”)
{
returnnewA();
elseif(parm==”B”)
returnnewB();
}
returnnull;
}
}
This is the abstraction of logic, this is the concreteness of methods, and this is the philosophy of programming.