Application framework Design (1): Introduction to SW System

"Application Framework Design" is my graduation thesis (2000) when I graduated from university. When I gave a lecture on "Application Architecture" within my company, I was attached as an entry-level reference. Later, I didn't know how to spread to the Internet, but an incomplete version (you can try searching for "application framework Design: SW system" in Google). Looking back at this text, the biggest feeling that their writing skills are more and more backward:-) Because of the interface with the library, you may wish to see.

Application Framework Design

Xu Xiwei

June 2000

I. Summary

With the development of object-oriented technology, many famous application frameworks have emerged, such as MFC, VCL, OWL, etc. under the Windows platform, and Turbo Vision under the old DOS system. Here I would like to use the "SW system" I designed to illustrate some of my thoughts on designing the application framework. The main elements involved are:

Basic content of application framework Design

This section is primarily about the necessity and feasibility of the application framework, as well as the basic ideas for designing the application framework.

The overall content and realization of SW system

This section focuses on the overall structure and content of the SW system as an application framework, and explains some important implementation details of the SW system. The main features are: Window model, attribute, RuntimeClass support and serialization of SW system in SW system. In the end, we want to analyze the flaws of the classic application framework. It also shows that the transition from SW system to COM is inevitable

The new direction of SW System: Application framework based on COM (component) idea

This part mainly introduces the basic content of component thought. The implementation of the component idea of SW system.

Second, the basic content of application framework Design

How many "bones" and how much "meat" does an application have? The term "meat" here refers to the part of the program that solves the problem, and "bone" refers to the part of the program frame that "meat" is attached to, which is what is necessary to interact with the user and make the interface friendly.

For the logic of problem solving, it is difficult to find a general approach to simplifying the matter. This can only be done if you are specifically positioned in a specific direction. For example, if you want to perform a numerical calculation, you may need a full-featured math package; You may need an image processing library to do the image process, and so on. Strictly speaking, these things are not a frame, just a kit (Utilities). Because they generally do not have complex calling rules, functions are fairly independent.

For applications interacting with users, people who program in the DOS era must be deeply impressed. The DOS period basically the program and the user interaction action All is completes by oneself. The result of this is often not felt in the interface design waste too much time, is to feel that the interface design is unsatisfactory. The framework code of each program has a lot of repetition, but because of the limitation of programming method, the reuse efficiency of program code is often relatively low.

The maturation of object-oriented thinking has prompted the emergence of various application frameworks. In object-oriented language, the relay of classes can be reused for a large number of ready-made code reuse; dynamic Banding (i.e. virtual function mechanism) technology effectively delays specific implementation code to design phase. An application structure called event-driven mode separates the framework code of the program from the implementation details. Although there are many types of application frameworks, they are quite consistent in their implementation: all of these application frameworks are an application of the event-driven model. This also includes the SW system to be introduced in this article.

The core of "event-driven" is naturally the event. From an event perspective, the basic structure of an event driver consists of an event collector, an event dispatcher, and an event handler. Event collectors are specifically responsible for collecting all events, including from users (such as mice, keyboard events, etc.), from hardware (such as clock events, and so on) and from software (such as the operating system, the application itself, and so on). The event dispatcher is responsible for distributing the events collected by the collector to the target object. Event handlers do specific incident response work, it is often to the implementation phase is completely determined, and therefore need to use the virtual function mechanism (function name is often similar to a handlemsg name). For users of the framework, the only thing they can see is the event handler. This is what they are concerned about.

The view (that is, what we usually call "Windows") is another element of the event-driven application. It is the target object of what we call the event dispatcher. The view accepts events and is able to process them. When we send an event to a specific view, we actually accomplish a fundamental change: from a traditional streamlined program structure to an event-triggering paradigm shift. The application is flexible enough to handle discrete, random events.