Modularization

Within a Presentation Manager application, it is recommended that the application code be separated into distinct source modules, as follows:

  • Each window procedure (that is, application object) should be placed in its own separate source module, along with functions and subroutines created for and exclusively called by that window procedure. This creates the situation where a single window is contained per source module, which preserves isolation and facilitates independence of application objects.

  • Type definitions, variable and constant declarations (including private message classes) and function prototypes that are local to a particular source module should be placed in a private header file or alternatively, included in the source module itself.

  • Function prototypes for those window procedures or subroutines that will become the entry points to the source module should be placed in a separate header file, along with type definitions, variable and constant declarations that will be required by other source modules calling those procedures or subroutines. This header file may then be referenced by each source module that requires access to these procedures or routines. This header file is known as the public header file.

  • Global type definitions, variable and constant declarations should be placed in a global header file that may be referenced by each source module. In the ideal case, global variables and constants should not be used by an application, and this header file would therefore not be required.

  • Generic functions and subroutines accessed by more than one window procedure should be placed in a separate source module with its own header file (known as a generic routines header file), which may be referenced by each module requiring access to the generic routines. This includes "functions" such as dialog definitions and dialog procedures that are accessed from multiple window procedures, and message handling routines.

  • Presentation Manager resources used by modules within an application should be placed in a resource script file, and their associated identifiers defined in the application's public header file.

    Note that a Workplace Shell object's source code is automatically partitioned in a similar manner to that described above, since the various files are created by the SOM Precompiler from the object's class definition file.

    Separation of the application code into its constituent application objects in this manner facilitates the isolation and independence of application objects, and enhances the potential for their subsequent reuse. It also eases the task of application maintenance and change management, by effectively modularizing an application and therefore helping to contain the scope of change within a single source module and its dependent header files.

    The separation of header files into private, public and global definitions in the manner described above further enhances the independence of application objects and facilitates change management, in the following ways:

  • The separation of an application object's public interfaces means that other application objects are aware only of those interfaces, and not of the internal definitions and operations of the application object. Changes within an application object, to local type, variable or constant definitions, do not impact other application objects with which the changed object communicates

  • The separation of the private and public interfaces explicitly defines each of these interfaces, so that a maintenance programmer is clearly aware of changes that will or will not impact other application objects. Other applications that do require modification as a result may be easily identified, since their source modules will contain a reference to the changed object's external interface header file.

    When managing the development of large projects, an "owner" should be appointed for each source module. This owner is typically a member of the development team who bears responsibility for that module. A module's owner should also have the responsibility for that module's private and public header files.

    [Back: Application Program Construction]
    [Next: Header Files]