From COBOL to OOP
Written for the experienced COBOL programmer, this nuts and bolts guide offers a comprehensive introduction to OOP techniques, and provides a migration of 10 million lines of COBOL code to object-oriented programming.
TABLE OF CONTENTS From COBOL to OOP
3.6: Modules
3.6 Modules
Modules are similar to external subprograms
This tutorial discusses modules. Modules are similar to external subprograms of COBOL, and even copies in COBOL are not unlike the modules discussed here. In COBOL, you can use the command COPY to embed program parts so that subprograms, particularly data definitions, can be managed in separate text files. However, when a copy changes, all programs that import this copy have to be recompiled. This is not the case with modules.
This section discusses the motivation for modules. Subsequently, it explains in detail what such modules look like and how they can be used. Finally, it describes rules to implement modularization.
3.6.1 Motivation
Splitting things into manageable parts
Modules split a program into manageable parts. This is a familiar technique: Section 2.4 presented the stepwise refinement technique, which is aimed at splitting complex things into smaller, more manageable parts. Another benefit of modules is their abstraction capabilities. Details can be hidden. Such an abstraction forms the basis for dynamic data structures, which are described in Section 3.7.
Collecting declarations
Modules consist of a collection of declarations. This means that constants, types, variables, and procedures are defined within modules. Each module can be compiled by itself, thereby serving as a building block others can use.
The essential features of a module are its interfaces, which define what is defined in the module and what will be made available for others. The declarations contained in these interfaces are called public, because this...
Copyright Elsevier, Inc. 2004 under license agreement with Books24x7
