Section 17.1.  Modular Code

17.1. Modular Code Modularization is the process by which you break up large blocks of code into smaller pieces (modules) that can be called by other modules. Modularization of code is analogous to normalization of data, with many of the same benefits and a few additional advantages. With modularization , your code becomes: More reusable By breaking up a large program or entire application into individual components that "plug-and-play" together, you will usually find that many modules are used by more than one other program in your current application. Designed properly, these utility programs could even be of use in other applications! More manageable Which would you rather debug: a 10,000-line program or five individual 2,000-line programs that call each other as needed? Our minds work better when we can focus on smaller tasks. You can also test and debug on a smaller scale (called unit testing ) before individual modules are combined for a more complicated system test. More readable Modules have names, and names describe behavior. The more you move or hide your code behind a programmatic interface, the easier it is to read and understand what that program is doing. Modularization helps you focus on the big picture rather than on the individual executable statements. More reliable The code you produce will have fewer errors. The errors you do find will be easier to fix because they will be isolated within a module. In addition, your code will be easier to maintain because there is less of it and it is more readable. Once you become proficient with the different iterative, conditional, and cursor constructs of the PL/SQL language (the IF statement, loops, etc.), you are ready to write programs. You will not really be ready to build an application, however, until you understand how to create and combine PL/SQL modules. PL/SQL offers the following structures that modularize your code in different ways: Procedure A program that performs one or more actions and is called as an executable PL/SQL statement. You can pass information into and out of a procedure through its parameter list. Function A program that returns a single value and is used just like a PL/ SQL expression. You can pass information into a function through its parameter list. Database trigger A set of commands that are triggered to execute (e.g., log in, modify a row in a table, execute a DDL statement) when an event occurs in the database. Package A named collection of procedures , functions, types, and variables. A package is not really a module (it's more of a meta-module), but it is so closely related that I mention it here. Object type or instance of an object type. Oracle's version of (or attempt to emulate) an object-oriented class. Object types encapsulate state and behavior, combining data (like a relational table) with rules (procedures and functions that operate on that data). Packages are discussed in Chapter 18; database triggers are explored in Chapter 19. You can read more about object types in Chapter 25. This chapter focuses on how to build procedures and functions, and how to design the parameter lists that are an integral part of well-designed modules. I use the term module to mean either a function or a procedure. As is the case with many other programming languages, modules can call other named modules. You can pass information into and out of modules with parameters. Finally, the modular structure of PL/SQL also integrates tightly with exception handlers to provide all-encompassing error-checking techniques (see Chapter 6). This chapter explores how to define procedures and functions, and then dives into the details of setting up parameter lists for these programs. We also examine some of the more "exotic" aspects of program construction, including local modules, overloading, forward referencing, deterministic functions, and table functions.