Build scalable applications (1)
Chris Sells Translation: Jackal L. Faven
Translation: I have been partially applying for the original text.
Many developers are all love the design and development ideas. Under the guidance of this idea, we can easily add new components in existent applications to get new features. They are all expected to use component-based programming to build applications that can be extended in operation. However, the components of the design phase and the components used in the end user are still very different. Developers can use considerable ready-made tools to develop applications or web pages: such as MFC, VC, VB, Java, VBScript, IE3, and more. But unfortunately, these tools cannot be in turn to help other similar tools use the applications you have developed. In this case, even if the user gets the source code of your application, there is only a few people who have enough funds to get a Mircorsoft Developer Studio and embed the components he just bought into your application. To provide scalability, you need to design your own application like a small nails to provide a hole to allow the user to get any nails that they want to nail. Of course, we must also give the specifications of this nailing small hole to make the nail board can choose the right nail. Under the Windows platform, you have two ways to choose from to provide this scalable ability, which is to use dynamic connection libraries (DLL, DYNAMIC LINK LIBRARIES) or using COM. First, let's review the so-called classic approach (ie, use dynamic connection libraries) and look at those shortcomings. Then, let us carefully study the method of applying COM. After we study one example, you have enough ability to build your own scalable application. You need to build a manager (Component Category Manager), which is included in the latest version of Win32 SDK, COMCAT.H, VC 4.2, and ActiveX SDK to compile the examples used herein. (All procedures have been compiled under Windows 95 OSR2 and Windows NT 4.0.)
Classic method
You may have been familiar with this classic approach: almost unavoidable with all Windows programmers to deal with DLL. A DLL can, for example, provide encapsulation, modular, and some other object-oriented functional advantages, while you can also load memory in any time. When a DLL is compiled near an application, it will expose all of our interfaces. As you can, there is such a very common fact that there is such a very common fact that the application software is put on the DLL outside it. The classic example of this extension method is very good, but it has an outdated spell check. It can be widely used in your commercial application. When there is a better component, you can also replace it to increase its competitive strength in the price war with software distributors. This is all the benefits, let's look at an independent example: Name Inspector. NameChecker is an expandable software that allows users to enter a series of names and check them through the user-specified check engines. NameChecker knows how to find a cheaper check engine showing a series of description names, while remembering the association of the document and check engine. You may want to separate Mac Wizards and UNIX GURUS, then use the appropriate engine. The key to this design is that each check engine must be based on the same, standardized interface. Using a classic DLL solution, the interface looks like this:
//NameCheckengine.h Bool WinAPI Checkname (LPCSTR SZNAME); Void WinAPI Suggestname (LPCSTR SZNAME, LPSTR SZSUGGESTION); any DLL exposed to this global function can be loaded and called in this way: typedef bool (WinAPI * pFNCHECKNAME) (LPCSTR); typedef void (WINAPI * PFNSUGGESTNAME) (LPCSTR, LPSTR); void CheckNames (const char * pszEngine, char * rgszNames, int nNames) {HINSTANCE hinst = LoadLibrary (pszEngine); if (hinst) {pFNCHECKNAME pfnCheckName = (pFNCHECKNAME) GetProcAddress (hinst, "CheckName"); pFNSUGGESTNAME pfnSuggestName = (pFNSUGGESTNAME) GetProcAddress (hinst, "SuggestName"); // re-iterate the table name // call pfnCheckName () and pfnSuggestName () FreeLibrary (hinst);} } LoadingLibrary () and getProcAddress () are the core of this method. Many Windows programs work in this way - such as Microsoft Office's import export engine, Adobe Photoshop, and image filtration, and more. Windows's shell (shell) also applies this way to load the control panel's applet. More than the operating system itself also uses this way to load the device driver. Each such scalable program has its independent API, and independently looks for "registered" components. These can be included in a registered item database, but also means that these DLLs are placed in the correct directory and ensure the correct naming rules. In theory, this design has no problem. When a set is properly added, the user can get a new feature. But in fact, there will be many problems exposing, including: a large number of getProcadDress () code versions are chaotic (see your own system), which is separated from object-oriented coding, and use modular API programming formation The application is incorrectly registered with the system to implement the programming interface (usually C or C or C or C or C ) to implement this programming interface (if it is still possible on the network?)
Hey, there is so much question, don't worry, we can celebrate that we have a COM method.
Translation: I translate the original Application as an application, not software.
