Java Reference
In-Depth Information
MOVE ZEROS TO MYSUB-SIZE.
* Call MYSUB, passing only one parameter.
* The stored string in MSG-TEXT will be evaluated.
CALL "MYSUB" USING MYSUB-CONTROL.
DISPLAY "MSG-TEXT: ", MSG-TEXT,
" MSG-SIZE: ", MSG-SIZE.
EXIT-PROGRAM.
EXIT PROGRAM.
STOP RUN.
I have demonstrated how a developer can support multiple interfaces to a sin-
gle COBOL subroutine. This avoids the problem of having to write and support
two separate yet similar routines; a single routine can perform both roles. However,
care must be exercised in both building and using the routine to make sure that the
proper interface is being used at the proper time. A calling program can easily cause
a runtime error by requesting one type of interface but not passing the proper
number of parameters.
Java's compiler and runtime system support this technique more explicitly and
with much more functionality. The developer does not need to worry about which
interface will be called and which parameter(s) may or may not be available; in-
stead, the compiler automatically takes care of these details.
Remember the distinctions that have made between MYSUB's CONTROL-AREA
and the other parameters passed to MYSUB? In these examples, every call to
MYSUB must pass the CONTROL-AREA, regardless of the other parameters
passed. Only the other parameters are optional.
This is similar to the way Java distinguishes between member data items and
passed parameters. Class member items are always available, regardless of the in-
terface used. For example, one method may require a single integer parameter and
return a
String
data type, whereas another accepts no parameters and does not re-
turn a data type (i.e., its return type is void). However, both of these methods can
access any of the class members, both the public and the private ones. The caller, on
the other hand, can access only the public class members, either before or after per-
forming the method.
Let's return, for a moment, to the Java example. This call to the method
getErrorMsg
(by the CALLER) will always perform the method in
ErrorMsg
that
accepts no parameter and returns a
String
result:
