Sprucing Up Your Code with Local Modules

These days it seems that whenever I write a program with more than 20 lines and any complexity whatsoever, I end up creating several local modules. Doing so helps me see my way through to a solution much more easily; I can conceptualize my code at a higher level of abstraction by assigning a name to a whole sequence of statements; and I can perform top-down design and stepwise refinement of my requirements. Finally, by modularizing my code even within a single program, I make it very easy to later extract a local module and make it a truly independent, reusable procedure or function.

I hope that as you read this, a program you have written comes to mind. Perhaps you can go back and consolidate some repetitive code, clean up the logic, and make the program actually understandable to another human being. Don't fight the urge. Go ahead and modularize your code.

16.6 Module Overloading

When more than one program in the same scope share the same name, the programs are said to be overloaded. PL/SQL supports the overloading ofprocedures and functions in the declaration section of a block (named or anonymous), package specifications and bodies, and object type definitions. Overloading is a very powerful concept, and you should exploit it fully to improve the usability of your software.

Here is a very simple example of three overloaded modules defined in the declaration section of an anonymous block (therefore, all are local modules):

DECLARE /* First version takes a DATE parameter. */ FUNCTION value_ok (date_in IN DATE) RETURN BOOLEAN IS BEGIN RETURN date_in <= SYSDATE; END; /* Second version takes a NUMBER parameter. */ FUNCTION value_ok (number_in IN NUMBER) RETURN BOOLEAN IS BEGIN RETURN number_in > 0; END; /* Third version is a procedure! */ PROCEDURE value_ok (number_in IN NUMBER) IS BEGIN IF number_in > 0 THEN DBMS_OUTPUT.PUT_LINE (number_in || 'is OK!'); ELSE DBMS_OUTPUT.PUT_LINE (number_in || 'is not OK!'); END IF; END; BEGIN

When the PL/SQL runtime engine encounters the following statement:

IF value_ok (SYSDATE) THEN ...

the actual parameter list is compared with the formal parameter lists of the various overloaded modules, searching for a match. If one is found, PL/SQL executes the code in the body of the program with the matching header.

Another name for overloading is static polymorphism. The term polymorphism refers to the ability of a language to define and selectively use more than one form of a program with the same name. When the decision on which form to use is made at compilation time, it is called static polymorphism. When the decision is made at runtime, it is called dynamic polymorphism; this type of polymorphism is available through inherited object types.

Overloading can greatly simplify your life and the lives of other developers. This technique consolidates the call interfaces for many similar programs into a single module name, transferring the burden of knowledge from the developer to the software. You do not have to try to remember, for instance, the six different names for programs adding values (dates, strings, Booleans, numbers, etc.) to various PL/SQL tables. Instead, you simply tell the compiler that you want to add a value, and pass it that value. PL/SQL and your overloaded programs figure out what you want to do and then do it for you.

When you build overloaded modules, you spend more time in design and implementation than you might with separate, standalone modules. This additional time up-front will be repaid handsomely down the line, as you and others will find it much easier and more efficient to use your programs.