Why use interfaces? Programming (conversion) read Interface Programming Article , A thorough understanding. Record:
For more information, seeProgramJust the history of language development, Mr. Lu Xun said, "governing the history of academic studies", understanding the past and present of the development of programming language, can we know why such a multi-language is like this, why?
After the emergence of computers, scientists have developed a variety of languages, from smalltalk, Pascal, basic, C, C ++, Java ,. net and so on, the pace of development of these languages can be seen as a historical development from process-oriented to object-oriented. When many object-oriented Books introduce their own history, they will introduce this history to readers and advocate how excellent OO programming is. The problem is that many people who have just started learning programs do not know why this change is necessary. They also have difficulty understanding the purpose of concepts such as virtual functions and interfaces in OO language.
Before learning about this history, we will first introduce the concept of "granularity". What is granularity? The author believes that the so-called granularity is actually used in a program.CodeThe unit combination scale, we can give an example, gravel-brick-house template, we want to build a house, there are actually many construction methods, if you don't have trouble, you can use gravel to build a building, or burn the gravel into bricks, build it with bricks, or even directly build the doors, windows, and wall components of the house 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.
When learning Pascal in the early days, the teacher told us that the most basic unit of this process-oriented language is process and function, 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 increase 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, the interface appeared. The inventor of C ++ was a lot of resistance when he first proposed the concept of a pure virtual function (actually an interface, many people do not understand what the interface means. We use virtual functions. Why is there an empty shelf for anything? 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.doc ument. 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, we have gone into the concept of COM after so many times. Before officially introducing COM, we have to come to the last point: the history of computer language development, 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 later we used classes. Now we use interfaces for a single purpose, so that the components we operate on can find a balance between specifics and abstractions. 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 = "")
{
Return new ();
Else if (parm = "B ")
Return new B ();
}
Return NULL;
}
}