External Interface Header File
Each source module should possess its own public header file. The public
header file should contain:
Function prototypes for the entry-point functions
or subroutines within the source module, and only for those routines.
This preserves the isolation of the source module's internal workings from
the calling application.
Type definitions for any application-defined data
types required by the entry-point functions or subroutines.
Message class definitions for application-defined
message classes that will be used to signal events to a window procedure
within the source module.
A public header file should be referenced by its own source module and by
any other source module which requires access to the entry points of the
module. In an ideal case, where optimum isolation is achieved by relating
all processing within the source module to a single window, access to these
entry points would be achieved by:
A single "conventional" subroutine call to create
the window, with the caller specifying appropriate parameters and the called
routine returning a handle to the window. The public header file must therefore
contain definitions for any application-defined data types to be passed
as parameters to this call.
Passing a series of messages to the window in order
to indicate events and request actions. The public header file must therefore
also contain definitions for any application-defined message classes used
by the window.
Since the public header file contains the interfaces to its parent window
(that is, application object) it should be carefully documented, and the
entry points and their means of access should be placed in the application's
design documentation. Interfaces to those application objects that are
identified as having potential for reuse should also be placed in an Interface
Control Document from which they may be accessed for future reuse
of the application object (see Packaging).
[Back: Private Header File]
[Next: Global Header File]