Application Object Modules
If the foregoing guidelines are followed, each object module produced by
the C language compiler will contain the following:
Definitions for all locally defined data types, variables
and constants required by routines within the module, obtained from the
module's private header file at compile time
Prototypes for all local window procedures, functions
and subroutines accessed only by routines within the module, obtained from
the application's private header file at compile time
Definitions for all external data structures, variables
and constants required to communicate with other source modules, obtained
from one or more public header files at compile time
Prototypes for all external window procedures, functions
and subroutines accessed by routines within the module, other than those
that constitute generic routines, obtained from one or more public header
files at compile time
Declarations for all global variables and constants
required by routines within the module, obtained from the application's
global header file at compile time
Prototypes for all generic routines, obtained from
the application's generic routines header file at compile time
Code for those routines contained within the module.
Each object module therefore exists as a coherent identity in its own right,
and ideally has no dependence upon other object modules, other than the
need to communicate with and make use of window procedures, functions and
subroutines contained within those modules, which is achieved through public
interfaces that are clearly defined and documented. The separation of source
modules is now carried over to the object code, in that each object module
represents a separate application object.
It is therefore possible to assemble a number of object modules in various
ways to achieve an executable application. The following guidelines are
offered for the construction of the executable application.
[Back: Packaging]
[Next: Application Executable File]