Data Abstraction and Encapsulation

In order to enhance reusability and to facilitate the containment (and therefore the management) of change, data definition and initialization should, wherever possible, be encapsulated within source modules as follows:

  • Local variables should be used wherever possible. Where the value of a variable must be held between invocations of the same function or subroutine, the static keyword may be used in declaring the variable.

  • For window procedures where the values of variables must be held beyond the scope of processing a single message, a memory object may be allocated for the variable(s) and a pointer to that object stored in the window words of the window.

  • External data objects such as files, databases, etc., should be defined and accessed only from within a single window procedure and its dependent functions and subroutines. Definition of and/or establishment of access to such data objects should be performed upon window creation as part of the WM_CREATE message processing, and termination of access should be performed upon window closure as part of the WM_CLOSE message processing.

  • The use of global variables should be avoided wherever possible, although it is recognized that global variables are necessary in certain circumstances within a Presentation Manager application. Where global variables are to be used, they should be declared in the application's main source module (that is, the module that contains the application's main routine) and referenced from the application's global header file using the extern keyword.

  • Except in the case noted above, the use of external variable declarations using the extern keyword should be avoided wherever possible, since this creates an interdependence between source modules (and therefore between application objects) that may subsequently limit the potential for reuse of those objects. Variables should preferably be defined locally within a source module or alternatively, defined globally and referenced in the application's global header file.

  • Where non-local variables and/or constants (that is, variables and/or constants that are accessed only from within a particular source module, but are not local to any routine within that module) are declared, they should be placed in that source module's private header file or, if the module does not possess its own header file, placed at the beginning of the source module.

    The practice of maximizing the use of local and encapsulated data, and of minimizing and simplifying the external interfaces of application objects, will achieve the maximum level of isolation and therefore of independence between application objects, thus enhancing the potential for their reuse and facilitating their future maintenance by isolating their internal workings from those of other application objects.


    [Back: System-Supplied Header Files]
    [Next: Packaging]