software applications. Typically, COBOL programs have a single entry point, which
makes the process of identifying reusable methods all but unnecessary because, instead of
declaring multiple entry points, it is general practice for legacy COBOL programs to
include functional discriminators in their I/O data structure(s) that indicate the desired
action(s) to be taken by the program on behalf of the caller. For example, a field called
“TRANSACTION-TYPE” with the possible values “DEP”, “WTH”, and “BAL” would
serve the same purpose in a COBOL program as the methods “doDeposit(δ)”,
“doWithdrawl(δ)“, and “getBalance(δ)” would serve in a Java program.
Figure 9.2. Mapping legacy functional discriminators to an object-oriented design.
Fig. 9.2 illustrates how a functional discriminator in a legacy COBOL data structure maps
to modern programming strategies such as object-oriented design.
In a real-world situation, we would be looking to reuse legacy components whose
machine code is the result of thousands of lines of high-level language statements
(COBOL) that implement a particular business process. Instead of going through the
error-prone process of rewriting the legacy component, which is likely decades old, we
wish to reuse and reengineer it so that it is easily consumed by modern programs and