A little bit of a feeling: separation of interfaces and programs

1 Windows desktop programs, interfaces and programs are source-level hybrid

Under the Windows System GUI program, the interface (GUI) and the other parts of the program are logically separated, but the source directly interacts with the interface function directly by invoking the Win32 API.

Example: CreateWindow ().
To write the Windows desktop program, you must call the GUI32.dll exported API without his optional.

Even the threading model has many features that are bound to a GUI window, such as Message Queuing.

2 Linux programs, interfaces and programs are communicated via Protocol 2.1 Cui programs and text terminals through terminal protocol interaction

For Cui's program, the text terminal provides interface functionality through a standard terminal protocol (line trip protocol). The text terminal and the host can run completely on the machine of different architectures, as long as each other complies with the same terminal communication protocol, the program and terminal can interact perfectly without being restricted by the communication medium.

Because of this, so that the remote terminal such as SSH and other convenient remote connection method is easy to understand and realize.

This complete separation brings a sense of perfection to the design.

Let every programmer to understand the use of Terminal protocol is very time-consuming (personally think very meaningful) things, and even more frightening is that the terminal protocol is not only one, each terminal equipment manufacturers have their own protocol extensions, such as VT100.

For ease of use, a library of functions for encapsulating terminal protocols has been developed. The most basic is the C standard function library in the printf (), scanf (). The more powerful feature is the famous curses library. When we write a Linux program to use these library functions, it is best to think of the terminal protocol under which it is supported.

2.2 GUI program and Xwindow server interact via x protocol

With the concept of text terminal same strain, Xwindow provides the function of the graphical terminal. The program interacts with the graphical terminal Xwindow server through the standard X protocol.

The function of the graphics terminal is much more powerful than the text terminal, and its communication data volume is greatly increased. All this leads to the complexity of the X protocol. So it is obviously too cumbersome to invoke the GUI function directly through the X protocol. Therefore, people developed a package x protocol Xlib Library, in order to more simple use, based on the Xlib library has developed a variety of advanced packaging libraries, such as GTK,QT.

When we use these library functions, don't forget that the bottom end is to use the X protocol to communicate with the graphics terminal.

2.3 Direct-operated video card is not a terminal

Linux supports direct operation of the graphics device, especially for framebuffer, making it easy to read and write directly to the graphics card. However, the operation of this kind of reading and writing interface is two completely different concepts. The interface of the Linux program is the terminal, as for how the terminal uses the graphics card that is the specific implementation of the terminal, the Linux program is not visible. Even the simplest printf (), the Linux program is written to the terminal, rather than directly to the graphics card. For the local terminal, the terminal and the program run on the same machine, it is easy to confuse the terminal and the graphics device. Keep in mind that the local terminal is only a special kind of terminal, when understanding the concept of the terminal, it is best to imagine the remote terminal situation.

3 Web programs, Interface (HTML) and back-end programs communicate via standard HTTP protocols

Although the Web program is also a graphical interface program, but the back end of the program to control the interface is very granular, and the program can not actively initiate to the interface of communication, these restrictions cause the HTTP protocol is very simple, the amount of communication data is very small.

The simpler things tend to be more successful, the Web program finally gets brilliant, becomes the mainstream of the program model, more and more desktop programs are replaced with the web version of the function.

Of course, because the Web backend program has limited function to the interface, so a large number of graphic image programs will not be replaced by the web.

4 separation or mixing?

is the interface and the program logic separated or mixed well? Logically, the interface function is a very mature independent module, from the point of view of modular design, separation is the most perfect choice. However, for graphics-intensive programs and frequently interacting programs (such as Photoshop,3d Max), the interface function occupies a large part of the program logic, and the fluency of the interaction becomes critical. Interface separation of the program interaction efficiency is bound to be affected, so Windows and Mac graphics interface interaction is much more fluent than Xwindow.

However, graphics-intensive and interactive-intensive programs occupy only a small part of the software market, and for the vast majority of other types of programs, the separation of the interface will undoubtedly bring the design aesthetic and concise, stable operation. Look at most of the servers, embedded devices.

In addition, hardware technology is often improved more easily than software design improvements, so as the level of hardware improvement, the separation of the interface will be the ultimate winner.

5 protocol or API?

The interaction of different modules in the program can be divided into: (1) Source code level mixing, (2) API function, and (3) protocol according to the coupling degree.

Source-level blending refers to the disclosure of data structure implementation details, unless it is a very simple program, otherwise this design is basically inappropriate;

API function level, refers to the design of a module as a library, external exposure of limited functions, using transparent data structure pointers as function parameters, all modules must be run with the same machine, the same process.

Protocol level, refers to the external exposure of communication standards, modules through the standard protocol to interact. At this point, different modules can be run on different machines.

There is also a multi-process programming approach between (2) and (3), where each module is run as a separate process, and the modules communicate through the native IPC.

In the process of programming, it is necessary to determine the mode of interaction between modules according to the size of the program, the specific business logic and the expansion requirements.

A little bit of a feeling: separation of interfaces and programs